[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. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |