[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V6 4/5] xen/mm: Clean up pfec handling in gva_to_gfn
Hi, At 15:30 +0800 on 19 Jan (1453217458), Huaitong Han wrote: > At the moment, the pfec argument to gva_to_gfn has two functions: > > * To inform guest_walk what kind of access is happenind > > * As a value to pass back into the guest in the event of a fault. > > Unfortunately this is not quite treated consistently: the hvm_fetch_* > function will "pre-clear" the PFEC_insn_fetch flag before calling > gva_to_gfn; meaning guest_walk doesn't actually know whether a given > access is an instruction fetch or not. This works now, but will cause > issues when pkeys are introduced, since guest_walk will need to know > whether an access is an instruction fetch even if it doesn't return > PFEC_insn_fetch. > > Fix this by making a clean separation for in and out functionalities > of the pfec argument: > > 1. Always pass in the access type to gva_to_gfn > > 2. Filter out inappropriate access flags before returning from gva_to_gfn. This seems OK. But can you please: - Add this new adjustment once, in paging_gva_to_gfn(), instead of adding it to each implementation; and - Adjust the comment above the declaration of paging_gva_to_gfn() in paging.h to describe this new behaviour. Also: > diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c > index 58f7e72..bbbc706 100644 > --- a/xen/arch/x86/mm/shadow/multi.c > +++ b/xen/arch/x86/mm/shadow/multi.c > @@ -3668,6 +3668,12 @@ sh_gva_to_gfn(struct vcpu *v, struct p2m_domain *p2m, > pfec[0] &= ~PFEC_page_present; > if ( missing & _PAGE_INVALID_BITS ) > pfec[0] |= PFEC_reserved_bit; > + /* > + * Intel 64 Volume 3, Section 4.7: The PFEC_insn_fetch flag is > + * set only when NX or SMEP are enabled. > + */ > + if ( !hvm_nx_enabled(v) && !hvm_smep_enabled(v) ) > + pfec[0] &= ~PFEC_insn_fetch; This needs to either DTRT for PV guests or assert that it always sees a HVM guest (I think this is the case but haven't tested). Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |