From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8mBZ-0006Zo-8F for qemu-devel@nongnu.org; Fri, 03 Jun 2016 06:18:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8mBK-0006UD-TZ for qemu-devel@nongnu.org; Fri, 03 Jun 2016 06:18:36 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:60671 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8mBK-0006U1-On for qemu-devel@nongnu.org; Fri, 03 Jun 2016 06:18:22 -0400 Received: from pps.filterd (m0048817.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u53AFhaD021988 for ; Fri, 3 Jun 2016 06:18:22 -0400 Message-Id: <201606031018.u53AFhaD021988@mx0a-001b2d01.pphosted.com> Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 23b3aqvayx-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 03 Jun 2016 06:18:22 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 3 Jun 2016 11:18:20 +0100 Date: Fri, 3 Jun 2016 12:18:15 +0200 From: David Hildenbrand In-Reply-To: <20160603112014.57782148@nial.brq.redhat.com> References: <1464799050-11002-1-git-send-email-imammedo@redhat.com> <201606022044.u52KaIkv017063@mx0a-001b2d01.pphosted.com> <20160603000209.GM19055@thinpad.lan.raisama.net> <20160603083621.6547bde4@thinkpad-w530> <20160603112014.57782148@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Eduardo Habkost , qemu-devel@nongnu.org, peter.maydell@linaro.org, mark.cave-ayland@ilande.co.uk, blauwirbel@gmail.com, qemu-arm@nongnu.org, pbonzini@redhat.com, rth@twiddle.net > > e.g. in terms of s390x: z13 includes both vx and tx > > -cpu z13,vx=off,tx=off > Above -cpu template will be translated into a corresponding > global properties template: > > -global z13-s390-cpu.vx=off -global z13-s390-cpu.tx=off This description makes it much clearer how you expect -cpu to behave. Thanks. The important part for me was that -global applies to this cpu type only. And our internal hierarchy should make sure that this is guaranteed. And good to known that it is a common schema we are following here. > > d) object_new("z13-s390-cpu")); // will I get a clean z13 with tx and vx on? > nope, you'll z13 with tx and vx off > > > d) has to work for us. Otherwise we will have to fallback to manual > > property parsing. > could you elaborate more why do you need (d) work > in combination with -cpu z13,vx=off,tx=off ? > Perhaps there is another way to do what you need. Say we started QEMU with -z13,vx=off,tx=off. When I do a QMP query to e.g. compare two cpu models, say a temporary cpu zBC12,tx=on and zBC13,tx=on is created. And the additional parameters only affect these instances as I learned. When I now compare them, the result will depend on the way QEMU has been started. But most likely this is okay, as we expect this interface to be used without any cpu model at all. This then just has to be documented accordingly. > > Current code uses -cpu for creating homogeneous cpus of given type > (i.e.) as template and that's exactly what -global cpufoo,feat=x ... does. > > > > If all you need is to parse properties, why can't you reuse the > > > existing QOM/Device mechanisms to handle properties (the one used > > > by -device and device_add), instead of the -cpu code? > > > > We can, if my given example works. And the global properties > > don't interfere with cpus. > if you need pure -device/device_add handling then don't use > -cpu CPUFOO,feat=x,... template as its current semantic > is to create all CPUs of type CPUFOO with feat=x,... applied > > It is a bad thing as soon as they affect other devices. > > If I did a -cpu z13,tx=off, I don't expect > > > > a) a hot-plugged z13 to suddenly have tx=off > you should expect it though, as -cpu z13,tx=off is template > for all z13 CPUs, it's not per instance thingy > > > b) a hot-plugged zBC12 to suddenly have tx off > that will not have tx off unless zBC12 is inherited from z13 They don't inherit, so this should be fine. > > > Won't libvirt have to specify the cpu name either way in device-add? > > And your plan seems to be that the properties are suddenly implicit. > > I don't see a problem with libvirt having to specify the properties > > manually on device add. > libvirt could do verbose > #1 -device CPUFOO,feat1=x -device CPUFOO,feat1=x ... > or > #2 -cpu CPUFOO,feat1=x -device CPUFOO -device CPUFOO ... > which is equivalent of generic device syntax and not use -cpu at all: > #3 -global CPUFOO.feat1=x -device CPUFOO -device CPUFOO ... > > #3 is where we are heading to by making -device/device_add available for > CPUs. If you wish to have CPUs of the same type but with different > features, don't use global properties for that features. > Just like with any other device. So this should work for us, we just have to document that -global for cpus or -cpu should not be used when trying to work with the new QMP queries. Thanks for the explanation! David