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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.03.14 at 15:18, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxx> 
>>>>>> wrote:
>>>> On Mon, Mar 17, 2014 at 8:38 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>>>> On 17.03.14 at 04:30, Sarah Newman <srn@xxxxxxxxx> 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.

If it's really that way, then again - what's the point of making a
hypervisor change when the kernel alone can deal with it in its
entirety?

> * 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.

I think Xen should conceptually not try to guess things like this,
even more so that you're leaving out of the discussion other
(perhaps non-Linux) PV kernels.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel