[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
On 07.09.2012 17:52, Jan Beulich wrote: >>>> On 07.09.12 at 17:47, Stefan Bader <stefan.bader@xxxxxxxxxxxxx> wrote: >> On 07.09.2012 17:44, Jan Beulich wrote: >>> All of this still doesn't provide evidence that a plain upstream >>> kernel is actually having any problems in the first place. Further, >>> if you say EC2 has a crippled hypervisor patch - is that patch >>> available for looking at somewhere? >> >> It was not a hypervisor patch. It was one for the guest. This was the hack: > > So then why do you want to patch the upstream kernel? It won't > make that hack go away, nor will it help any existing kernels. > > Jan > It would not make it go away automatically, but whoever uses it could drop it. It was unpatched upstream kernels that would have the problem. However, while reading again through all the changelogs I noticed commit 61f4237d5b005767a76f4f3694e68e6f78f392d9 Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx> Date: Sat Sep 18 22:25:30 2010 -0700 xen: just completely disable XSAVE Some (old) versions of Xen just kill the domain if it tries to set any unknown bits in CR4, so we can't reliably probe for OSXSAVE in CR4. Since Xen doesn't support XSAVE for guests at the moment, and no such support is being worked on, there's no downside in just unconditionally masking XSAVE support. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> So until then the write to CR4 was deliberately done to probe the feature. This was changed by commit 947ccf9c3c30307b774af3666ee74fcd9f47f646 Author: Shan Haitao <haitao.shan@xxxxxxxxx> Date: Tue Nov 9 11:43:36 2010 -0800 xen: Allow PV-OPS kernel to detect whether XSAVE is supported Xen fails to mask XSAVE from the cpuid feature, despite not historically supporting guest use of XSAVE. However, now that XSAVE support has been added to Xen, we need to reliably detect its presence. The most reliable way to do this is to look at the OSXSAVE feature in cpuid which is set iff the OS (Xen, in this case), has set CR4.OSXSAVE. [ Cleaned up conditional a bit. - Jeremy ] Signed-off-by: Shan Haitao <haitao.shan@xxxxxxxxx> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> This would make it save again _if_ the HV failing to handle the writes to CR4 (which iirc the kernel code still does when the cpuid bit is set) does have at least the patch to mask off the cpuid bits (the one Ian mentioned) Probably a lot of hand wavy iffs... :/ Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |