[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Getting the XSAVE size from userspace
On 05/11/15 11:35, Andrei LUTAS wrote: > On 11/5/2015 12:51 PM, Jan Beulich wrote: >>>>> On 05.11.15 at 11:49, <andrew.cooper3@xxxxxxxxxx> wrote: >>> On 05/11/15 10:42, Jan Beulich wrote: >>>>>>> On 05.11.15 at 10:52, <rcojocaru@xxxxxxxxxxxxxxx> wrote: >>>>> I need to get the XSAVE size from userspace. The easiest way seems >>>>> to be >>>>> to use the XEN_DOMCTL_getvcpuextstate hypercall, but that >>>>> hypercall is >>>>> not public / there's no xenctrl.h wrapper for it. >>>> Before going into any detail of the rest of your mail - any reason you >>>> can't just consult CPUID output? >>> It depends on precisely what you want. >>> >>> CPUID.0xD[0].ecx gives you the maximum xsave area on this processor >>> CPUID.0xD[0].ebx gives you the current size for the value in xcr0, but >>> that is not very useful from userspace. >> Why would the maximum size not be sufficient for most (all?) user >> mode purposes? >> >> Jan >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxx >> http://lists.xen.org/xen-devel >> > Hello, > > The use-case is the following: whenever an EPT violation is triggered > inside a monitored VM, the introspection logic needs to know how many > bytes were accessed (read/written). This is done by inspecting the > faulting instruction and directly inferring the size, which is not > straight-forward for XSAVE/XRSTOR family. Using the maximum possible > size is wrong, as in any given moment the OS may or may not desire to > XSAVE/XRSTOR the entire state (and thinking that the instruction tries > to access more than it actually does may yield undesired effects). > Therefore, the size needed for the currently enabled features of the > monitored guest is required instead. Normally, it could be done by > running CPUID with eax = 0xD and ecx = i, where i >= 2 and XCR0[i] is > 1 (XCR0 belongs to the monitored guest), but I am unsure if using > CPUID this way would be safe/desired: will Xen expose the same CPUID > features, for XSAVE related functionality, on all VMs? (using XCPUID > with eax = 0xD and ecx = 0 would give us the needed size for the SVA, > and like I said, using the maximum size would not be safe, even if > it's the same across all VMs on a given host). Also, I'm unsure how > this would get along with migration... Hmm yes - there is no way to do this currently. Xen's CPUID handling for xsave related things is broken in levelling and migration scenarios, which is why it is *still* disabled by default in XenServer. I am working on fixing it, and will take this usecase into account (although I think I had already included enough for this usecase to work). At the point of the xsave/xrestor trap, you need to know xcr0 and be able to perfom a cpuid instruction in the context of a target domain, to make use of 0xD[0].ebx to get the "current size based on xcr0". ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |