Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device

[Peter Krempa <pkrempa@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]

On Wed, Dec 16, 2015 at 16:11:08 +0100, Igor Mammedov wrote:
> On Fri, 11 Dec 2015 09:27:57 +0530
> Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
> 
> > On Thu, Dec 10, 2015 at 01:35:05PM +0100, Igor Mammedov wrote:
> > > On Thu, 10 Dec 2015 11:45:35 +0530
> > > Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:

[...]

> > > For initial conversion of x86-cpus to device-add we could do pretty
> > > much the same like we do now, where cpu devices will appear under:
> > > /machine (pc-i440fx-2.5-machine)
> > >   /unattached (container)
> > >     /device[x] (qemu64-x86_64-cpu)
> > > 
> > > since we don't have to maintain/model dummy socket/core objects.
> > > 
> > > PowerPC could do the similar only at core level since it has
> > > need for modeling core objects.
> > > 
> > > It doesn't change anything wrt current introspection state, since
> > > cpus could be still found by mgmt tools that parse QOM tree.
> > > 
> > > We probably should split 2 conflicting goals we are trying to meet
> > > here,
> > > 
> > >  1. make device-add/dell work with cpus /
> > >      drop support for cpu-add in favor of device_add 
> > > 
> > >  2. how to model QOM tree view for CPUs in arch independent manner
> > >     to make mgmt layer life easier.
> > > 
> > > and work on them independently instead of arguing for years,
> > > that would allow us to make progress in #1 while still thinking
> > > about how to do #2 the right way if we really need it.
> > 
> > Makes sense, s390 developer also recommends the same. Given that we
> > have CPU hotplug patchsets from x86, PowerPC and s390 all
> > implementing device_add semantics pending on the list, can we hope to
> > get them merged for QEMU-2.6 ?
> > 
> > So as seen below, the device is either "cpu_model-cpu_type" or just
> > "cpu_type".
> generic device_add isn't able to deal with 'cpu_model' stuff, so
> it should be concrete 'cpu_type'.
> Question is if libvirt can get a list of supported CPU types. 
> 
> > 
> > -device POWER8-powerpc64-cpu (pseries)
> > -device qemu64-x86_64-cpu (pc)
> > -device s390-cpu (s390)
> > 
> > Is this going to be the final acceptable semantics ? Would libvirt be
> > able to work with this different CPU device names for different
> > guests ?
> CCing Peter to check if libvirt could do it nad if his is ok with
> proposed device_add semantics as in the it's he who will deal with it
> on libvirt side.

Well, this depends entirely on the implementation and the variety of the
cpu device models. Libvirt requires that the cpu model for a given
arch/machine type/whatever can be inferred either completely offline or
via monitor commands that are available when qemu is started with the
'none' machine type. This is required as we query capabilities of a qemu
binary beforehand and then use the cached data to create the command
line. Running a qemu process just to query a cpu model is not acceptable
as it adds significant overhead.

Peter

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]