[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, tak
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7 |
Date: |
Fri, 31 Jan 2014 17:25:59 -0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Jan 31, 2014 at 08:18:39PM +0100, Igor Mammedov wrote:
> On Fri, 31 Jan 2014 11:56:18 -0700
> Eric Blake <address@hidden> 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.
AFAIK, libvirt logic about CPU model features doesn't even take into
account that it may change depending machine-type. I believe getting the
non-machine-type-specific data will be better than the current state
where libvirt relies on the data from cpu_map.xml, which duplicates (and
sometimes don't match) what's inside QEMU.
We will also need a way to figure out machine-type-specific information
about each CPU model without re-running QEMU, but I think we can do this
one step at a time.
--
Eduardo
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, (continued)
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Paolo Bonzini, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Igor Mammedov, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Paolo Bonzini, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31
- Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eric Blake, 2014/01/31
- Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31
- Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Igor Mammedov, 2014/01/31
- Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7,
Eduardo Habkost <=