[libvirt] [Qemu-devel] [PATCH RFC 4/8] target-i386: cpu: consolidate calls of object_property_parse() in x86_cpu_parse_featurestr

[Eduardo Habkost]

On Fri, Jun 03, 2016 at 11:37:49AM +0200, Igor Mammedov wrote:
> On Fri, 3 Jun 2016 09:30:09 +0200
> Peter Krempa <pkrempa at redhat.com> wrote:
> 
> > On Thu, Jun 02, 2016 at 18:31:04 +0200, Igor Mammedov wrote:
> > > On Thu, 2 Jun 2016 17:05:06 +0200
> > > Peter Krempa <pkrempa at redhat.com> wrote:  
> > > > On Thu, Jun 02, 2016 at 11:53:22 -0300, Eduardo Habkost wrote:  
> > > > > On Thu, Jun 02, 2016 at 02:22:22PM +0200, Igor Mammedov wrote:  
> > 
> > [...]
> > 
> > > > I couldn't find anything regarding xlevel (so we might actually not
> > > > support it at all), but we indeed do limit the hv_spinlock count:
> > > > 
> > > > 
> > > >                 if (def->hyperv_spinlocks < 0xFFF) {
> > > >                     virReportError(VIR_ERR_XML_ERROR, "%s",
> > > >                                    _("HyperV spinlock retry count must be "
> > > >                                      "at least 4095"));
> > > >                     goto error;
> > > >                 }
> > > > 
> > > > Peter  
> > > Peter,
> > > Does libvirt still uses -cpu xxx,+feat1,-feat2 syntax
> > > or canonical property syntax there feat1=on,feat2=off  
> > 
> > We use the legacy one:
> > 
> > -cpu core2duo,+ds,+acpi,+ht,+tm,+ds_cpl, ...
> > 
> > and
> > 
> > -cpu 'qemu32,hv_relaxed,hv_vapic, ... 
> > 
> > for the hyperv features.
> > 
> > We probably can switch to the new one if there's a reasonable way how to
> > detect that qemu is supporting the new one.
> for x86 features became properties since 2.4 release (commit 38e5c119),
> that's the one way to know it.
> But it's still only +-features for sparc (that's the last remaining
> target that has legacy parsing).
> 
> Another way to detect it is to probe via QOM if CPU has a property corresponding
> to a feature.
> 
> Maybe Eduardo knows about other ways to do it.

The properties could be detected by running
device-list-properties when libvirt is probing for QEMU binary
capabilities. But we still don't return any useful information
for abstract classes or X86CPU subclasses.

You could work around it by running qom-list on the first VCPU
object, but when libvirt probes QEMU binary capabilities, it uses
-machine none (which doesn't create any VCPU).

I will look for other mechanisms that can be used in QEMU
2.{4,5,6} already, but I am not sure we will find one.

If all fails, we can consider making query-command-line-options
return useful data for -cpu on QEMU 2.7.

-- 
Eduardo