On Tue, Jun 09, 2015 at 09:56:25AM +0100, Daniel P. Berrange wrote: > On Mon, Jun 08, 2015 at 10:18:35PM +0200, Jiri Denemark wrote: > > On Mon, Jun 08, 2015 at 16:07:38 -0300, Eduardo Habkost wrote: > > ... > > > libvirt can solve this problem partially by making sure every feature in > > > a CPU > > > model is explicitly configured, instead of (incorrectly) expecting that a > > > named > > > CPU model will never change in QEMU. But this doesn't solve the problem > > > completely, because it is still possible that new features unknown to > > > libvirt > > > get enabled in the default CPU model in future machine-types (that's very > > > likely to happen when we introduce new KVM features, for example). > > > > > > So, to make sure no new feature will be ever enabled without the > > > knowledge of > > > libvirt, add a "-cpu custom" mode, where no CPU model data is loaded at > > > all, > > > and everything needs to be configured explicitly using CPU properties. > > > That > > > means no CPU features will ever change depending on machine-type or > > > accelerator > > > capabilities when using "-cpu custom". > > > > > > * * * > > > > > > I know that this is basically the opposite of what we were aiming at in > > > the > > > last few month^Wyears, where we were struggling to implement probing > > > interfaces > > > to expose machine-type-dependent data for libvirt. But, at least the fact > > > that > > > we could implement the new approach using a 9-line patch means we were > > > still > > > going in the right direction. :) > > > > > > To help libvirt in the transition, a x86-cpu-model-dump script is > > > provided, > > > that will generate a config file that can be loaded using -readconfig, > > > based on > > > the -cpu and -machine options provided in the command-line. > > > > Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU > > configuration data to libvirt, but now I think it actually makes sense. > > We already have a partial copy of CPU model definitions in libvirt > > anyway, but as QEMU changes some CPU models in some machine types (and > > libvirt does not do that) we have no real control over the guest CPU > > configuration. While what we really want is full control to enforce > > stable guest ABI. > > I meanwhile, always wanted the full CPU config data in libvirt, so that > we could ensure libvirt was able to use the exact same CPU model setup > on other hypervisors too - eg Xen, VMWare let us specify the CPUID masks > so we could re-use the libvirt data there. > > > I will summarize my ideas on how libvirt should be using -cpu custom and > > send them to libvirt-list soon. > > These patches are x86 obviously - is there anything we need to worry about > for non-x86 architectures I wonder ? IIRC, all the non-x86 archs have > traditionally only needed CPU model names and don't really have the same > level of per-flag CPUID mask configurability that x86 has.
X86 started with opaque CPU model names hiding implementation details, then moved to allow extra -cpu parameters. Then we noticed that the CPU models were hiding too much from libvirt in the X86 case, and now those parameters were converted to become QOM properties configurable using -global. I expect other architectures to follow a similar pattern and allow things to be configured using QOM properties, but I am not sure they would go to the extreme of making every single detail configurable using QOM. One thing you may need to worry about for all architectures is to check if a CPU model is runnable in a host before starting or migrating a VM. In this case, we're introducing a generic mechanism in query-cpu-definitions for that. See "[PATCH v6 15/17] target-s390x: Extend arch specific QMP command query-cpu-definitions" and related patches (posted on 2015-04-27) on qemu-devel. And in the case of runnability checks, x86 is a bit more complex, too (because it is too configurable in QEMU and in libvirt): as libvirt needs to know what exactly is blocking the CPU from running, we have the "filtered-features" property (that libvirt can start using, now that we have the "qom-path" field on query-cpus). -- Eduardo
