[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.