[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch 2/4] Refining Xsave/Xrestore support
I once considered this problem, too. Originally, I suppose I can use CR4 switching when entering/leaving PV guest, as what HW is doing for us in VMX. But I suspect this will bring a lot of overhead. Later I picked the current implementation, hoping guest applications can have a check on XCR0 first before it uses extended states. And according to spec, in order to use extend states, XCR0 must be set, but this is a ring 0 instruction only. Shan Haitao 2010/10/28 Jan Beulich <JBeulich@xxxxxxxxxx>: >>>> On 28.10.10 at 09:55, Haitao Shan <maillists.shan@xxxxxxxxx> wrote: >> In my patch, if processor supports CR4.OSXSAVE, Xen will enable it and >> won't clear it as long as we are in ROOT mode. > > Ah, okay. There's one problem with this, however - a pv domain the > kernel of which doesn't support xsave would still see CPUID report > the OSXSAVE bit set, and hence applications could be lead to > believe they can use the wider registers. I realize this also puts > under question our model of having the kernel look at CPUID's > OSXSAVE bit, but that could possibly be dealt with by having > pv_cpuid() (and perhaps xc_cpuid_pv_policy()) set the bit in case > Xen supports xsave. > > Jan > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |