Re: [Qemu-devel] [PATCH 6/7] target-i386: add implementation of query-cpudefs

[Anthony Liguori <aliguori@us.ibm.com>]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Fri, Aug 10, 2012 at 11:37:30AM -0500, Anthony Liguori wrote:
>> Eduardo Habkost <ehabkost@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