Re: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
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(a)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(a)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(a)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(a)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(a)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(a)redhat.com>
Cc: Markus Armbruster <armbru(a)redhat.com>
Signed-off-by: Anthony Liguori <aliguori(a)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