qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Alexander Graf]

On 19.01.2012, at 13:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> 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

> 
> 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
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
> 

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Alexander Graf]

On 19.01.2012, at 13:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> 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

> 
> 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
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
> 

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-19 14:24, Alexander Graf wrote:
> 
> 
> On 19.01.2012, at 13:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>> 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-19 14:24, Alexander Graf wrote:
> 
> 
> On 19.01.2012, at 13:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>> 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Alexander Graf]

On 19.01.2012, at 14:30, Jan Kiszka wrote:

> On 2012-01-19 14:24, Alexander Graf wrote:
>> 
>> 
>> On 19.01.2012, at 13:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> 
>>> 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.

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

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Alexander Graf]

On 19.01.2012, at 14:30, Jan Kiszka wrote:

> On 2012-01-19 14:24, Alexander Graf wrote:
>> 
>> 
>> On 19.01.2012, at 13:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> 
>>> 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.

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

Re: qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Marcelo Tosatti]

On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
> 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.

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Marcelo Tosatti]

On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
> 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.

Re: qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-19 18:28, Marcelo Tosatti wrote:
> On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
>> 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.
> 

Then I guess he should comment on this after returning to work. :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-19 18:28, Marcelo Tosatti wrote:
> On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
>> 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.
> 

Then I guess he should comment on this after returning to work. :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Avi Kivity]

On 01/19/2012 07:39 PM, Jan Kiszka wrote:
> On 2012-01-19 18:28, Marcelo Tosatti wrote:
> > On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
> >> 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.
> > 
>
> 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.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Avi Kivity]

On 01/19/2012 07:39 PM, Jan Kiszka wrote:
> On 2012-01-19 18:28, Marcelo Tosatti wrote:
> > On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
> >> 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.
> > 
>
> 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.

-- 
error compiling committee.c: too many arguments to function

Re: qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-25 12:38, Avi Kivity wrote:
> On 01/19/2012 07:39 PM, Jan Kiszka wrote:
>> On 2012-01-19 18:28, Marcelo Tosatti wrote:
>>> On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
>>>> 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.
>>>
>>
>> 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-25 12:38, Avi Kivity wrote:
> On 01/19/2012 07:39 PM, Jan Kiszka wrote:
>> On 2012-01-19 18:28, Marcelo Tosatti wrote:
>>> On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
>>>> 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.
>>>
>>
>> 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Avi Kivity]

On 01/25/2012 01:57 PM, Jan Kiszka wrote:
> > 
> > -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.

> 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.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Avi Kivity]

On 01/25/2012 01:57 PM, Jan Kiszka wrote:
> > 
> > -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.

> 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.

-- 
error compiling committee.c: too many arguments to function

Re: qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-25 13:04, Avi Kivity wrote:
> On 01/25/2012 01:57 PM, Jan Kiszka wrote:
>>>
>>> -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.

OK.

> 
>> 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-25 13:04, Avi Kivity wrote:
> On 01/25/2012 01:57 PM, Jan Kiszka wrote:
>>>
>>> -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.

OK.

> 
>> 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Avi Kivity]

On 01/25/2012 02:10 PM, Jan Kiszka wrote:
> > 
> >> 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.

> Do we have alternatives? A top-level command line options is surely none.

  -kvm shadow-memory=n,...

  -accel kvm,shadow-memory=n,...

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Jan Kiszka]

On 2012-01-25 13:15, Avi Kivity wrote:
> On 01/25/2012 02:10 PM, Jan Kiszka wrote:
>>>
>>>> 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.

Which is NOT guest visible.

> 
>> 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?

[Avi Kivity]

On 01/25/2012 02:26 PM, Jan Kiszka wrote:
> On 2012-01-25 13:15, Avi Kivity wrote:
> > On 01/25/2012 02:10 PM, Jan Kiszka wrote:
> >>>
> >>>> 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.
>
> 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.

> > 
> >> 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".

Okay.  I have an uneasy feeling about machine options for this, but
nothing more.

-- 
error compiling committee.c: too many arguments to function