[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


 


Rackspace

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