12:09 p.m.
Eduardo Habkost <ehabkost(a)redhat.com> writes:
On Fri, Aug 10, 2012 at 11:37:30AM -0500, Anthony Liguori wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
> >> > - add machine-type-specific cpudef compatibility changes?
> >>
> >> I think we've discussed this in IRC. I don't think we need to
worry
> >> about this.
> >
> > I remember discussing a lot about the mechanism we will use to add the
> > compatibility changes, but I don t know how the query API will look
> > like, after we implement this mechanism.
>
> 0) User-defined CPU definitions go away
> - We already made a big step in this direction
>
> 1) CPU becomes a DeviceState
1.1) CPU models become classes
>
> 2) Features are expressed as properties
>
> 3) Same global mechanism used for everything else is used for CPUs
This is basically the compatibility mechanism we agreed upon, yes, but
what about the probing mechanism to allow libvirt to know what will be
the result of "-machine M -cpu C"[1] before actually starting a VM?
I think that the requirement of "before actually starting a VM" is
unreasonable.
Presumably migration compatibility checking would happen after launching
a guest so libvirt could surely delay querying the CPUID info until
after the guest has started.
There's a lot of logic involved in deciding what gets exposed to the
guest. We don't really fully know until we've created the VCPU. It's a
whole lot easier and saner to just create the VCPU.
Regards,
Anthony Liguori
[1] By "result" I mean:
- Whether that combination can be run properly on that host;
- Which CPU features will be visible to the guest in case it runs.
Both items depend on CPU model _and_ machine-type, that's why we need
some probing mechanism that depends on the machine-type or use the
machine-type as input.
>
> Regards,
>
> Anthony Liguori
>
> >> > Would the command report different results depending on -machine?
> >>
> >> No.
> >
> > The problem is:
> >
> > 1) We need to introduce fixes on a CPU model that changes the set of
> > guest-visible features (add or remove a feature)[1];
> > 2) The fix has to keep compatibility, so older machine-types will
> > keep exposing the old set of gues-visible features;
> > - That means different machine-types will have different CPU
> > features being exposed.
> > 3) libvirt needs to control/know which guest-visible CPU features are
> > available to the guest (see above);
> > 4) Because of (2), the querying system used by libvirt need to depend on
> > the CPU model and machine-type.
> >
> >
> > [1] Example:
> > The SandyBridge model today has the "tsc-deadline" bit set, but
> > QEMU-1.1 did not expose the tsc-deadline feature properly because of
> > incorrect expectations about the GET_SUPPORTED_CPUID ioctl. This was
> > fixed on qemu-1.2.
> >
> > That means "qemu-1.1 -machine pc-1.1 -cpu SandyBridge" does _not_
> > expose tsc-deadline to the guest, and we need to make "qemu-1.2
> > -machine pc-1.1 -cpu SandyBridge" _not_ expose it, too (otherwise
> > migration from qemu-1.1 to qemu-1.2 will be broken).
> >
> >>
> >> >
> >> > Would the command return the latest cpudef without any machine-type
> >> > hacks, and libvirt would have to query for the cpudef compatibility
data
> >> > for each machine-type and combine both pieces of information itself?
> >>
> >> I'm not sure what you mean by compatibility data.
> >
> > I mean any guest-visible compatibility bit that we will need to
> > introduce on older machine-types, when making changes on CPU models (see
> > the SandyBridge + tsc-deadline example above).
> >
> > I see two options:
> > - Libvirt queries for a [f(machine_type, cpu_model) -> cpu_features]
> > function, that will take into account the machine-type-specific
> > compatibility bits.
> > - Libvirt queries for a [f(cpu_model) -> cpu_features] function and a
> > [f(machine_type) -> compatibility_changes] function, and combine both.
> > - I don't like this approach, I am just including it as a possible
> > alternative.
> >
> >>
> >> Regards,
> >>
> >> Anthony Liguori
> >>
> >> >
> >> > [1] Note that it doesn't have to be low-level leaf-by-leaf
> >> > register-by-register CPUID bits (I prefer a more high-level
> >> > interface, myself), but it has to at least say "feature FOO
is
> >> > enabled/disabled" for a set of features libvirt cares about.
> >> >
> >> > --
> >> > Eduardo
> >>
> >
> > --
> > Eduardo
>
--
Eduardo