From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <20140131192559.GF2221@otherpad.lan.raisama.net> References: <1391111339-6958-1-git-send-email-ehabkost@redhat.com> <20140131154853.34c41154@thinkpad> <52EBB82F.7020001@redhat.com> <20140131151753.GY2221@otherpad.lan.raisama.net> <20140131170621.3857e584@thinkpad> <20140131164207.GZ2221@otherpad.lan.raisama.net> <52EBD4E9.2000700@redhat.com> <20140131185137.GD2221@otherpad.lan.raisama.net> <52EBF1D2.7090800@redhat.com> <20140131201839.640523b7@thinkpad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eric Blake , Paolo Bonzini , kvm@vger.kernel.org, libvir-list@redhat.com, qemu-devel@nongnu.org, Jiri Denemark , Andreas =?iso-8859-1?Q?F=E4rber?= To: Igor Mammedov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34899 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932499AbaAaT0F (ORCPT ); Fri, 31 Jan 2014 14:26:05 -0500 Content-Disposition: inline In-Reply-To: <20140131201839.640523b7@thinkpad> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Jan 31, 2014 at 08:18:39PM +0100, Igor Mammedov wrote: > On Fri, 31 Jan 2014 11:56:18 -0700 > Eric Blake 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=-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