qemu-devel
[Top][All Lists]
Advanced

[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: Eric Blake
Subject: Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
Date: Fri, 31 Jan 2014 11:56:18 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]