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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx>
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@xxxxxxxxxx>
Cc: Markus Armbruster <armbru@xxxxxxxxxx>
Signed-off-by: Anthony Liguori <aliguori@xxxxxxxxxx>
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list