From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq22d-0007Is-36 for qemu-devel@nongnu.org; Wed, 25 Jan 2012 07:33:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rq22Z-0002pX-0m for qemu-devel@nongnu.org; Wed, 25 Jan 2012 07:33:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq22Y-0002pT-O4 for qemu-devel@nongnu.org; Wed, 25 Jan 2012 07:33:26 -0500 Message-ID: <4F1FF693.4080100@redhat.com> Date: Wed, 25 Jan 2012 14:33:23 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4F1810AF.8010002@siemens.com> <20120119172802.GD11381@amt.cnet> <4F185535.1060908@siemens.com> <4F1FE9CE.5050401@redhat.com> <4F1FEE1F.8080907@siemens.com> <4F1FEFCA.2060907@redhat.com> <4F1FF13E.5090405@siemens.com> <4F1FF247.80301@redhat.com> <4F1FF50A.3070403@siemens.com> In-Reply-To: <4F1FF50A.3070403@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Marcelo Tosatti , qemu-devel , kvm 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