[libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing

[Eduardo Habkost]

On Thu, May 15, 2014 at 02:14:18PM +0200, Igor Mammedov wrote:
> On Tue, 6 May 2014 17:19:57 -0300
> Eduardo Habkost <ehabkost at redhat.com> wrote:
> 
> > On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> > > On Tue, 6 May 2014 11:42:56 -0300
> > > Eduardo Habkost <ehabkost at redhat.com> wrote:
> > > 
> > > > On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
> > > > > On Fri, 2 May 2014 11:43:05 -0300
> > > > > Eduardo Habkost <ehabkost at redhat.com> wrote:
> > > > > 
> > > > > > On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> > > > > > > On Wed, 30 Apr 2014 17:29:28 -0300
> > > > > > > Eduardo Habkost <ehabkost at redhat.com> wrote:
> > > > > > > 
> > > > > > > > This series allows management code to use object-add on X86CPU subclasses, so it
> > > > > > > Is there any reason why "device-add" couldn't be used?
> > > > > > 
> > > > > > It needs to work with "-machine none", device_add requires a bus to
> > > > > > exist, and there is no icc-bus on machine_none.
> > > > > The thing is that CPUID is a function of machine so using
> > > > > "-machine none" will provide only approximately accurate data.
> > > > > I'm not sure that retrieved possibly not accurate data are useful
> > > > > for libvirt.
> > > > 
> > > > "-cpu host" doesn't depend on machine, and is the most important thing
> > > > right now (because libvirt's checks for host QEMU/kernel/CPU
> > > > capabilities is completely broken).
> > > true, but device-add/-cpu host could be used right now to get the
> > > same CPUID data wile using any machine type or default one without
> > > any of this patches.
> > 
> > device_add can't be used with "-machine none".
> Well, does caller need to use -machine in this case at all?
> Why not call QEMU with default machine type and get the same info
> using device_add ??

I guess the explanation for "-machine none" is at:

commit b4a738bf93c3137b92d532e59d60edccc4e1ea96
Author: Anthony Liguori <aliguori at us.ibm.com>
Date:   Wed Aug 22 15:22:05 2012 -0500

    boards: add a 'none' machine type to all platforms

    This allows any QEMU binary to be executed with:

      $QEMU_BINARY -M none -qmp stdio

    Without errors from missing options that are required by various boards.  This
    also provides a mode that we can use in the future to construct machines
    entirely through QMP commands.

    Cc: Daniel Berrange <berrange at redhat.com>
    Cc: Markus Armbruster <armbru at redhat.com>
    Signed-off-by: Anthony Liguori <aliguori at us.ibm.com>

libvirt runs QEMU with "-machine none" before it knows anything about the QEMU
binaries. There are many target architectures where the default machine-type
won't work without extra options.

15 of the 26 qemu-system-* binaries on my Fedora 20 system failed to run as:
  $QEMU -nodefaults -no-user-config -nographic -monitor stdio

(All of them ran happily when I added "-M none".)


> 
> > 
> > > 
> > > > 
> > > > About machine-type data: currently libvirt has no concept of
> > > > per-machine-type CPU model data, anyway. We (and libvirt) will need to
> > > > address this eventually, but considering our track record, I bet the
> > > > QEMU community will take a few years to finally provide that info to
> > > > libvirt.
> > > I don't think QEMU is issue here, libvirt can use device-add to
> > > probe accurate CPUID on all CPU models on a given machine type now.
> > > libvirt should be fixed to care about machine type and use it to get
> > > correct CPUID data that QEMU provides.
> > 
> > True, it should. But we still need a solution for the "-cpu host" problem.
> As you've said before '-cpu host' doesn't depend on machine type so 
> libvirt could use "device_add 'host-cpu'" with default or any other
> PC machine type right now.

But not with "-machine none".

-- 
Eduardo