Re: [libvirt] [RFC] qemu: Redesigning guest CPU configuration

On Fri, Jun 19, 2015 at 02:27:27PM +0200, Daniel Hansel wrote: > currently Michael Mueller (IBM) is working on an extension > of QEMU to support CPU models for s390x platform. > During the discussion on the QEMU mailing list the implementation > was done in a more common way to provide support for all platforms. > > According to that new implementation I have implemented a first > version for libvirt to retrieve the CPU model(s) supported by > QEMU on s390x. > Due to the fact that the discussion is ongoing my prototype is > not ready to be tested yet. > > A short overview about the current prototype I have implemented > (QEMU cpu model support patches from Michael Mueller required): > > 1. During start of libvirt daemon QEMU monitor is used to retrieve > the CPU models (i.e. just model names, QEMU handles all other > setting like features, etc.) QEMU is supporting. > 2. The supported CPU models are stored in libvirt's QEMU capabilities > (and stored in the capabilities cache file). > 3. Each call of virConnectGetCPUModelNames() (i.e. > qemuConnectGetCPUModelNames()) is retrieving the information from > QEMU capabilities (cached or not) on s390x platform. > All other platforms remain on the currently implemented way to parse > the cpu_map.xml. > > Depending on that implementation all requests to get CPU models (e.g. > for CPU model comparison, CPU model listing) will lead to a more > appropriate result (e.g. if a QEMU binary is exchanged by a QEMU > binary built manually). I can't really speak for Jiri and I haven't look at QEMU s390 in any detail, but as a general point, we'll want to try to use the same approach for dealing with CPUs across all architectures. What Jiri describes has been written from POV of x86, but we need to make sure it works on s390 and other arches just as well. We especially want to avoid having two completely separate codepaths for this in libvirt dependant on arch.

Regards, Daniel