Re: [PATCH] x86: Control CR0 TS behavior using dev_na_ts_allowed

[George Dunlap <george.dunlap@eu.citrix.com>]

On 03/17/2014 02:05 PM, George Dunlap wrote:
> On 03/17/2014 01:35 PM, Jan Beulich wrote:
>>>>> On 17.03.14 at 13:42, George Dunlap <George.Dunlap@eu.citrix.com> 
>>>>> wrote:
>>> On Mon, Mar 17, 2014 at 8:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 17.03.14 at 04:30, Sarah Newman <srn@prgmr.com> wrote:
>>>> Not being convinced at all that this is the right approach (in
>>>> particular it remains unclear how an affected guest should deal with
>>>> running on a hypervisor not supporting the new interface)
>>> It looks like the intention of this patch was that if the dom0
>>> administrator enables the new option, then it will be on by default,
>>> *but* the guest can disable the new behavior.  That way, if an admin
>>> knows that she's running all PVOPS kernels (no "classic Xen" kernels),
>>> she can enable it system-wide.  Older PVOPS kernels will behave
>>> correctly (but a bit slowly), and newer PVOPS kernels will switch to
>>> the PVABI behavior and reap the performance benefit.
>>>
>>> Newer PVOPS kernels running on older hypervisors will simply use the
>>> PVABI behavior.
>> But if that works correctly, then there's no hypervisor/tools
>> change needed in the first place.
>
> Yes, there's still a need to run *old* PVOPS kernels on *new* 
> hypervisors.  That (as I understand it) is the point of this patch.

So we have old hypervisors, new hypervisors with this disabled, and new 
hypervisors with this enabled.  New hypervisors with this disabled 
behave just like old hypervisors.  And we have old pvops kernels, new 
pvops kernels, and "classic Xen" kernels.  And we have "correctness" and 
"performance".  Then we have the following combinations:

* Old hypervisor / New hypervisor w/ mode disabled:
  - Old hypervisor, classic kernel: correct and fast.
  - Old hypervisor, old pvops kernel: fast but buggy.
  - Old hypervisor, new pvops kernel: correct and fast.
* New hypervisor (w/ mode enabled):
  - classic kernel: broken (since it's expecting PVABI TS behavior)
  - old pvops: correct but slow
  - new pvops kernel: correct and fast (since it will opt-in to the 
faster PVABI)

Is there a way for Xen to tell if it's running a "classic Xen" port 
(which expects PVABI TS behavior), or a pvops kernel (which will either 
expect "hardware" TS behavior, or will know how to opt-in to PVABI TS 
behavior)?  That would relieve the admin of trying to figure out for 
each guest whether he had a classic or a pvops kernel.

  -George