[libvirt] [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7

Igor Mammedov imammedo at redhat.com
Fri Jan 31 19:18:39 UTC 2014

On Fri, 31 Jan 2014 11:56:18 -0700
Eric Blake <eblake at redhat.com> wrote:

> On 01/31/2014 11:51 AM, Eduardo Habkost wrote:
> >> Allowing -device may be okay, since in the (very?) long term -device
> >> can be replaced by -object.  But -object is definitive.
> > 
> > OK, one additional reason to try device_add first.
> > 
> > But then we have one additional problem:
> > 
> >  * We want to allow libvirt to probe for CPU model information when
> >    running QEMU using "-machine none" (because libvirt already does
> >    that, and we don't want to require libvirt to run QEMU multiple
> >    times)
> >  * "device_add driver=<model>-x86_64-cpu" requires an icc-bus to be present
> >  * -machine none doesn't have any bus
> >  * I don't see a way to create an icc-bus through QMP (is there a way?)
> Is the icc-bus something that makes sense for all architectures, so that
> libvirt could just blindly request a command line that uses '-machine
> none' but also instantiates the icc-bus?  Even if icc-bus is
> x86-specific, libvirt DOES have some notion of what architecture a qemu
> executable will be targetting, and could modify the command line based
> on what architecture it guesses the binary will support, if only for the
> purpose of minimizing qemu invocations for its probe of supported cpus.
Since -machine none, will not produce accurate CPUID info anyway and libvirt
knows in advance that it's going to create x86 machine, it might probe with
default machine type. It would be more accurate than -machine none,
but still might be not accurate if another machine type will be eventually
used for running guest.

> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org


More information about the libvir-list mailing list