qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?
Hi again,
do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream?
If yes: The underlying IOCTL is x86-only. Are other archs interested in this long-term as well, ie. should the control become arch-independent?
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 4 lines · Jan Kiszka
Hi again,
do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream?
What does it do? Never heard of it :)
Alex
Quoted 10 lines
If yes: The underlying IOCTL is x86-only. Are other archs interested in this long-term as well, ie. should the control become arch-independent?
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 10 lines · Alexander Graf
Quoted 4 lines · Jan Kiszka
Hi again,
do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream?
What does it do? Never heard of it :)
According to inline docs: "Chang[e] the number of mmu pages allocated to the vm". That's from arch/x86/kvm/mmu.c, kvm_mmu_change_mmu_pages(). That's soft-MMU related so, I bet, of decreasing relevance for x86.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Alexander Graf
Quoted 2 lines · Jan Kiszka
Hi again,
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream?
What does it do? Never heard of it :)
According to inline docs: "Chang[e] the number of mmu pages allocated to the vm". That's from
arch/x86/kvm/mmu.c,kvm_mmu_change_mmu_pages(). That's soft-MMU related so, I bet, of decreasing relevance for x86.
Ah, that's the maximum number of concurrently active pages we allow? Pretty cool, but it should be a monitor command rather than a command line option, no? And if we want it, we should have it available on other archs too, yes.
Alex
Quoted 9 lines · Jan Kiszka
Hi again,
do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream?
If yes: The underlying IOCTL is x86-only. Are other archs interested in this long-term as well, ie. should the control become arch-independent?
Jan
Last time i asked about removal, Avi wished for it to remain.
Quoted 6 lines · Marcelo Tosatti
Quoted 5 lines · Jan Kiszka
Hi again,
do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream?
Quoted 7 lines
Quoted 4 lines
If yes: The underlying IOCTL is x86-only. Are other archs interested in this long-term as well, ie. should the control become arch-independent?
Jan
Last time i asked about removal, Avi wished for it to remain.
Then I guess he should comment on this after returning to work. :)
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 10 lines · Jan Kiszka
Quoted 9 lines · Marcelo Tosatti
Quoted 8 lines · Jan Kiszka
Hi again,
do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream?
If yes: The underlying IOCTL is x86-only. Are other archs interested in this long-term as well, ie. should the control become arch-independent?
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Jan
Last time i asked about removal, Avi wished for it to remain.
Then I guess he should comment on this after returning to work. :)
-kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 13 lines · Avi Kivity
Quoted 12 lines · Jan Kiszka
Quoted 11 lines · Marcelo Tosatti
Quoted 9 lines · Jan Kiszka
Hi again,
do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in upstream?
If yes: The underlying IOCTL is x86-only. Are other archs interested in this long-term as well, ie. should the control become arch-independent?
Jan
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Last time i asked about removal, Avi wished for it to remain.
Then I guess he should comment on this after returning to work. :)
-kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization.
So, is it used for testing in fact? Would a machine option "kvm_shadow_memory=n" be desirable?
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 6 lines · Jan Kiszka
Quoted 4 lines
-kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization.
So, is it used for testing in fact?
It is not, but it should be. There's an extra_params option in autotest, I'll start using it to stress the mmu some more, even though it's going to slow things down for me.
Quoted 2 lines
Would a machine option
"kvm_shadow_memory=n" be desirable?
Not sure, this is a host option, not a guest option. Machine options should be guest-visible.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 11 lines · Avi Kivity
Quoted 6 lines · Jan Kiszka
Quoted 4 lines
-kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization.
So, is it used for testing in fact?
It is not, but it should be. There's an
extra_paramsoption in autotest, I'll start using it to stress the mmu some more, even though it's going to slow things down for me.
OK.
Quoted 6 lines
Quoted 3 lines
Would a machine option
"kvm_shadow_memory=n" be desirable?Not sure, this is a host option, not a guest option. Machine options should be guest-visible.
machine options are not guest visible. Basically, this options falls into the same category as kernel_irqchip.
Do we have alternatives? A top-level command line options is surely none.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 9 lines · Jan Kiszka
Quoted 6 lines
Quoted 3 lines
Would a machine option
"kvm_shadow_memory=n" be desirable?Not sure, this is a host option, not a guest option. Machine options should be guest-visible.
machine options are not guest visible. Basically, this options falls into the same category as
kernel_irqchip.
They should be. We should work hard to separate the guest ABI from everything else. Same as kvm-apic appearing in the qdev name.
Quoted 1 line
Do we have alternatives? A top-level command line options is surely none.
-kvm shadow-memory=n,...
-accel kvm,shadow-memory=n,...
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 5 lines · Avi Kivity
Quoted 4 lines · Jan Kiszka
Quoted 4 lines
Quoted 3 lines
Would a machine option
"kvm_shadow_memory=n" be desirable?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Not sure, this is a host option, not a guest option. Machine options should be guest-visible.
machine options are not guest visible. Basically, this options falls into the same category as
kernel_irqchip.They should be. We should work hard to separate the guest ABI from everything else. Same as kvm-apic appearing in the qdev name.
Which is NOT guest visible.
Quoted 6 lines
Quoted 2 lines
Do we have alternatives? A top-level command line options is surely none.
-kvm shadow-memory=n,...
-accel kvm,shadow-memory=n,...
Both are unneeded additional options.
We already have -machine option=value. We just need to enable machines like KVM-based ones to append their private ones to the common set. That way you will get a proper error report when specifying a meaningless combination like "accel=tcg,kernel_irqchip=on".
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 9 lines · Jan Kiszka
Quoted 8 lines · Avi Kivity
Quoted 7 lines · Jan Kiszka
Quoted 6 lines
Quoted 3 lines
Would a machine option
"kvm_shadow_memory=n" be desirable?Not sure, this is a host option, not a guest option. Machine options should be guest-visible.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
machine options are not guest visible. Basically, this options falls into the same category as
kernel_irqchip.They should be. We should work hard to separate the guest ABI from everything else. Same as kvm-apic appearing in the qdev name.
Which is NOT guest visible.
Right. I'm worried about some tool comparing the qdev/qom trees and concluding two machines are different even though they are identical wrt the guest. Too be fair, that applies to attributes as well.
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Do we have alternatives? A top-level command line options is surely none.
-kvm shadow-memory=n,...
Quoted 8 lines
Quoted 1 line
-accel kvm,shadow-memory=n,...
Both are unneeded additional options.
We already have -machine option=value. We just need to enable machines like KVM-based ones to append their private ones to the common set. That way you will get a proper error report when specifying a meaningless combination like "accel=tcg,kernel_irqchip=on".
Okay. I have an uneasy feeling about machine options for this, but nothing more.
Signature · 1 line
error compiling committee.c: too many arguments to function