[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/xsave: Remove xfeat_mask checking from validate_xstate()



On 02/06/14 11:43, Jan Beulich wrote:
>>>> On 02.06.14 at 12:07, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 02/06/14 07:43, Jan Beulich wrote:
>>>>>> On 30.05.14 at 13:57, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> What further sanity checking would be wanted/needed?
>>>>
>>>> The sending Xen must have gotten this correct else it wouldn't have an 
>>>> xsave area to send in the first place.  If the receiving the Xen found 
>>>> parts it didn't like, the local validity checks would fail.
>>>>
>>>> As far as I can see, the only case this might do something unexpected is 
>>>> if the individual xfeature_mask got changed on transit, at which point 
>>>> the receiving Xen would fail the xsave load, despite the xsave area 
>>>> being valid for the current cpu.
>>> Whether the loading would fail really depends on what exactly became
>>> corrupted.
>> The current behaviour is that the load would fail, as validate_xstate()
>> would fail.
> Oh, then we meant different things with "load" (I was assuming you
> meant the actual xrstor).

Ah no.  This is strictly only for loading the vcpu xsave state using
XEN_DOMCTL_setvcpuextstate or XEN_DOMCTL_sethvmcontext

There is no change for guest xsave interaction with Xen.


>
>>> But in the end the question is - are you intending to no longer
>>> communicate this bit of information in the v2 migration stream?
>> Ideally I would like to cease communicating this in the v2 stream.
> Okay, on that basis I'm willing to take the patch; any chance you
> could add a note to this effect to the commit message?
>
> Jan
>

I will reword it.

~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®.