From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics? Date: Wed, 25 Jan 2012 13:26:50 +0100 Message-ID: <4F1FF50A.3070403@siemens.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , qemu-devel , kvm To: Avi Kivity Return-path: Received: from thoth.sbs.de ([192.35.17.2]:24539 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752843Ab2AYM07 (ORCPT ); Wed, 25 Jan 2012 07:26:59 -0500 In-Reply-To: <4F1FF247.80301@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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