[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |