Re: [libvirt] [RFC] qemu: Redesigning guest CPU configuration
On Fri, Jun 19, 2015 at 15:43:02 +0100, Daniel P. Berrange wrote:
On Fri, Jun 19, 2015 at 04:36:34PM +0200, Jiri Denemark wrote:
> On Thu, Jun 18, 2015 at 14:41:17 +0100, Daniel P. Berrange wrote:
> > > So either we need to define all existing CPU models in all their
> > > variants used for various machine types and have a mapping between
> > > (model without a version, machine type) to a specific version of the
> > > model (which may be quite hard) or we need to be able to distinguish
> > > between an existing domain and a new domain with no CPU model version.
> > > While host-model and host-passthrough CPU modes are easy because they
> > > are designed to change everytime a domain starts (which means we
don't
> > > need to be able to distinguish between existing and new domains), custom
> > > CPU mode are tricky. Currently, the only at least a bit reasonable thing
> > > which came to my mind is to have a new CPU mode, but it still seems
> > > awkward so please share your ideas if you have any.
> >
> > Introducing a new CPU mode feels pretty unpleasant to me.
> >
> > Although it will certainly be tedious work, getting details of all the
> > CPU variants for historical machine types should be doable I think.
>
> Yeah, I also prefer this variant but I was kind of hoping someone would
> come up with a bright idea which would safe me from all the work :-P
Allow me to introduce you to perl and regexes :-P
Haha, I'm afraid it's not as simple since the machine type specific
tweaks to CPU models are done in the code, you can't just look at some
data structures to get all the variants. Actually, it has changed and
it's defined in macros now, but there is another way which does not need
a lot of work :-) Using a slightly modified (to produce a bit more
condensed output) x86-cpu-model-dump script from Eduardo and some shell
scripting around it I fetched all 700+ combinations of CPU models and
machine types and differences between subsequent variants of the same
CPU model. So this part was not that bad.
However, knowing all the details about a guest CPU used by QEMU for a
given CPU model on a specific machine type is not enough to enforce ABI
stability. Without using -cpu Model,enforce (or an equivalent of
checking filtered-features via QMP) QEMU may silently filter features it
cannot provide on the current host. Even in case of TCG some features
are not supported, e.g., -cpu SandyBridge will always fail to start in
enforcing mode. Even doing something ugly and using the enforce mode
only for new machine types is not going to work because after a QEMU
upgrade new libvirt would be incompatible with older libvirt.
That said, I don't really see a way to do all this automatically without
an explicit switch in a domain XML. Be it a new CPU mode or an attribute
which would request enforcing ABI stability.
Jirka