
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@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@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@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@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@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@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Anthony Liguori <aliguori@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