[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory sem
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics? |
Date: |
Wed, 25 Jan 2012 14:33:23 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 |
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
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, (continued)
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, Marcelo Tosatti, 2012/01/19
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, Jan Kiszka, 2012/01/19
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, Avi Kivity, 2012/01/25
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, Jan Kiszka, 2012/01/25
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, Avi Kivity, 2012/01/25
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, Jan Kiszka, 2012/01/25
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, Avi Kivity, 2012/01/25
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?, Jan Kiszka, 2012/01/25
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics?,
Avi Kivity <=