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

[Avi Kivity <avi@redhat.com>]

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