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

Re: [Xen-devel] [PATCH 5/7] x86/shadow: Use the pagewalk reserved bits helpers



>>> On 02.03.17 at 13:56, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 02/03/17 12:51, Jan Beulich wrote:
>>>>> On 02.03.17 at 13:26, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 01/03/17 16:03, Jan Beulich wrote:
>>>>>>> On 27.02.17 at 15:03, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> The shadow logic should never create a shadow of a guest PTE which 
>>>>> contains
>>>>> reserved bits from the guests point of view.  Such a shadowed entry might 
>>>>> not
>>>>> cause #PF[RSVD] when walked by hardware, thus won't behave architecturally
>>>>> from the guests point of view.
>>>> But are we already or-ing in the RSVD bit accordingly in such cases,
>>>> before handing the #PF to the guest? The patch here certainly
>>>> doesn't make any change towards that, afaics.
>>> The purpose of this patch is to ensure we never create a shadow which
>>> risks causing hardware to generate #PF[RSVD] when running on the
>>> shadows, other than the one deliberate case (MMIO fastpath).
>> Right, but instead of answering my question this emphasizes the
>> need for an answer, as what you say basically means we'd never
>> (except for that one special case) see the RSVD bit set when
>> getting #PF handed by hardware, yet for forwarding to the guest
>> we need to set that bit then in such cases.
> 
> This is intentional.
> 
> We hand #PF[RSVD] back to the guest based on walking the guest
> pagetables, rather than what we find from hardware walking the shadows
> we create.

Well, is that (always) the case here already, or only after patch 7? My
question after all is whether this works as intended at this point.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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