Re: [Qemu-devel] Semantics of "-cpu host" (was Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest)

[Alexander Graf]

On 07.05.2012, at 20:21, Eduardo Habkost wrote:

> 
> Andre? Are you able to help to answer the question below?
> 
> I would like to clarify what's the expected behavior of "-cpu host" to
> be able to continue working on it. I believe the code will need to be
> fixed on either case, but first we need to figure out what are the
> expectations/requirements, to know _which_ changes will be needed.
> 
> 
> On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote:
>> (CCing Andre Przywara, in case he can help to clarify what's the
>> expected meaning of "-cpu host")
>> 
> [...]
>> I am not sure I understand what you are proposing. Let me explain the
>> use case I am thinking about:
>> 
>> - Feature FOO is of type (A) (e.g. just a new instruction set that
>>  doesn't require additional userspace support)
>> - User has a Qemu vesion that doesn't know anything about feature FOO
>> - User gets a new CPU that supports feature FOO
>> - User gets a new kernel that supports feature FOO (i.e. has FOO in
>>  GET_SUPPORTED_CPUID)
>> - User does _not_ upgrade Qemu.
>> - User expects to get feature FOO enabled if using "-cpu host", without
>>  upgrading Qemu.
>> 
>> The problem here is: to support the above use-case, userspace need a
>> probing mechanism that can differentiate _new_ (previously unknown)
>> features that are in group (A) (safe to blindly enable) from features
>> that are in group (B) (that can't be enabled without an userspace
>> upgrade).
>> 
>> In short, it becomes a problem if we consider the following case:
>> 
>> - Feature BAR is of type (B) (it can't be enabled without extra
>>  userspace support)
>> - User has a Qemu version that doesn't know anything about feature BAR
>> - User gets a new CPU that supports feature BAR
>> - User gets a new kernel that supports feature BAR (i.e. has BAR in
>>  GET_SUPPORTED_CPUID)
>> - User does _not_ upgrade Qemu.
>> - User simply shouldn't get feature BAR enabled, even if using "-cpu
>>  host", otherwise Qemu would break.
>> 
>> If userspace always limited itself to features it knows about, it would
>> be really easy to implement the feature without any new probing
>> mechanism from the kernel. But that's not how I think users expect "-cpu
>> host" to work. Maybe I am wrong, I don't know. I am CCing Andre, who
>> introduced the "-cpu host" feature, in case he can explain what's the
>> expected semantics on the cases above.

Can you think of any feature that'd go into category B?

All features I'm aware of work fine (without migration, but that one is moot 
for -cpu host anyway) as long as the host kvm implementation is fine with it 
(GET_SUPPORTED_CPUID). So they'd be category A.


Alex