Am 06.02.2014 17:16, schrieb Eduardo Habkost: > (CCing libvir-list again, as this is continuing a discussion about a > subject that interests libvirt developers, from another thread.) > > On Thu, Feb 06, 2014 at 04:51:17PM +0100, Andreas Färber wrote: >> Am 06.02.2014 16:19, schrieb Igor Mammedov: >>> On Wed, 5 Feb 2014 17:52:16 +0100 >>> Igor Mammedov <imammedo@xxxxxxxxxx> wrote: >>> >>>> On Wed, 05 Feb 2014 17:14:27 +0100 >>>> Andreas Färber <afaerber@xxxxxxx> wrote: >>>> >>>>> Am 05.02.2014 15:40, schrieb Igor Mammedov: >>>>>> On Sun, 15 Dec 2013 23:50:47 +0100 >>>>>> Andreas Färber <afaerber@xxxxxxx> wrote: >>>>>> >>>>>>> Am 27.11.2013 23:28, schrieb Igor Mammedov: >>>>>>>> Igor Mammedov (16): >>>>>>>> target-i386: cleanup 'foo' feature handling' >>>>>>>> target-i386: cleanup 'foo=val' feature handling >>>>>>> >>>>>>> Thanks, I've queued these on qom-cpu-next: >>>>>>> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-next >>>>>>> >>>>>>>> target-i386: cpu: convert 'level' to static property >>>>>>>> target-i386: cpu: convert 'xlevel' to static property >>>>>>>> target-i386: cpu: convert 'family' to static property >>>>>>>> target-i386: cpu: convert 'model' to static property >>>>>>>> target-i386: cpu: convert 'stepping' to static property >>>>>>>> target-i386: cpu: convert 'vendor' to static property >>>>>>>> target-i386: cpu: convert 'model-id' to static property >>>>>>>> target-i386: cpu: convert 'tsc-frequency' to static property >>>>>>> >>>>>>> But I still don't see the utility of this conversion after all the >>>>>>> discussions we've had... :( >>>>>> It seems there is movement to make DEVICE self describing for purpose >>>>>> of QAPI schema introspection, where static properties would be used >>>>>> (dynamic ones are not suitable for this purpose) >>>>> >>>>> Do you have a pointer to such a discussion? Sounds like I was not >>>>> involved and Anthony probably not either... >>>> Not at the moment, CCing people who might know more about the topic. >>>> >>>> But just thinking about creating QAPI schema for devices, it's not really >>>> possible to generate one using dynamic properties (unless one resorts to >>>> creating every supported device instance), while arrays of static properties >>>> are there for every device and simplistically speaking just need conversion >>>> to schema format. >>> >>> There is one more reason to use static properties for external user-settable >>> properties when it comes to device, i.e. to get list of properties user could >>> use command: >>> #qemu -device x86_64-cpu,? >>> x86_64-cpu.pmu=boolean >>> x86_64-cpu.hv-spinlocks=int >>> x86_64-cpu.hv-relaxed=boolean >>> x86_64-cpu.hv-vapic=boolean >>> x86_64-cpu.check=boolean >>> x86_64-cpu.enforce=boolean >>> >>> which now yields only partial properties user is interested in, above >>> mentioned conversion patches make previously not available properties >>> visible to user via typical interface, perhaps eventually we could >>> drop list_cpu() interface in favor of -device foo-cpu,? command. >> >> We already brought that up specifically for decision on a KVM call and >> Anthony's clear statement was that the expected way for management tools >> to discover properties was to instantiate the object and run qom-list on it. > > As far as I remember, this was decided as the recommended way to list > the feature _default values_ (e.g. discover which features are going to > be enabled on each CPU model). Is this really the recommended way to > discover which properties can be set on device_add, too? We are not > going to have any other instrospection mechanism that won't require > objects to be created? It is, and no, no other introspection mechanism on the horizon. I specifically suggested to have a copy of the ObjectProperty list in ObjectClass (today it is just in Object) but Anthony rejected that idea due to the dynamic nature of properties in QOM and pointed us to said qom-list and object instantiation as the sole means for discovering availability of properties. And it's true that we could in fact just instantiate the object for -device foo,? - it's just that nobody wrote code for that. I didn't do the original QOM conversion so I don't feel guilty, I don't normally use -device foo,? so not affected, I followed Anthony's instructions for how to and how not to implement things. In a few cases Anthony has changed his mind (method inheritence for instance) but for that you'll need to discuss with him and not just argue with me about something that Anthony has decided in the past. That's just pissing me off because it feels like a waste of my time. >> It is a known issue, both for info qtree and -device, that they do not >> list all properties. But I don't want to repeat this discussion over and >> over again: Paolo's patches for static properties were rejected by >> Anthony, therefore I could not queue them on qom-next back then and >> therefore I had to code my properties for the X86CPU (which was not yet >> a device back then) the new QOM way, and now you're trying to override >> Anthony's decision in forcing me to accept patches that Anthony had >> vetoed against! >> >> If you or libvirt need all properties for -device, then send a patch. No >> one did for two years, so apparently no one cared. >> >> Static properties are considered a valid, convenient way to define >> properties for a device but not the sole one for a device or object. >> Using info qtree or -device as justification for implementation >> decisions is backwards and wrong since those are considered legacy. > > So, let me ask again, explicitly: we are not going to ever have a > QMP-based interface that will allow all available device_add options to > be queried without instantiating an object first? This really surprises > me. > > (That's not a question just for Andreas. I would like to hear from > Paolo, Anthony, and others.) > > >> >> And specifically for libvirt Eduardo pushed into a release properties >> that could be used to inspect CPUIDs. If that's not being used by >> libvirt, as Eduardo seems to imply now, why did we put work in that in >> the first place? > > It is not being used by libvirt because the current interface is > unusable without running QEMU once for each CPU model. With the CPU > model subclasses, we will be able to make it possible to create/destroy > CPUs of different models in a single QEMU instance, and then libvirt > will be able to use it. OK, that I understand now, so let's be sure to get (the remainder of) that subclasses series through my review mills in time for 2.0. :) >> If there's no relation between a CPU model named, e.g., "Haswell" and >> the one on an Intel Haswell chip any more, then we should give them >> artificial names like "qemu64"; I strongly believe that Haswell >> definition in code should match that of the specs/hardware and if TCG >> can't emulate something that's one thing (subtractive: no AVX) and if >> KVM wants to speed up things that's another (additive: kvmvapic, >> in-kernel IRQ/PIT). What I am arguing against is watering the meaning of >> our definitions from "this is this model" to "this is handy". In >> particular, if we use the post_initialize hook like I suggested then >> -global is still able to override it and Eduardo's properties should >> correctly report them to libvirt. > > "Haswell" is named this way not only because it looks like Haswell, but > also because it has useful features you are going to find only on > Haswell, and you (probably) are not going to be able to run it on hosts > older than Haswell. That's the main real-world application of CPU > models: making sure the VMs can run on a specific subset of hosts. So, > if you choose "Haswell", you are telling the management stack "I know > this is going to run only on Haswell and newer CPUs". > > That's why x2apic is being proposed as an exception: it can be enabled > on any host, because it doesn't depend on host-side support. That's why > I propose we enable it on CPU models that don't have x2apic in the real > world. > > (BTW, what is the relation between this subject and static properties? I > was expecting this to be discussed in the other existing thread about > x2apic) Sorry if I replied to two different series at once, that was for "Enabling x2apic by default in KvM (was Re: [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models)". Which is connected to CPU models/subclasses in what those types are supposed to be good for if we define them. Let's take an obvious example. Jan wants to emulate a legacy isapc machine with -cpu 486. Then it feels counterproductive to enable the latest and greatest features such a machine never had. If the user wants to have the latest and greatest features, she can choose a newer -cpu model which already has the flag today. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list