|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker
>>> On 13.05.16 at 15:33, <andrew.cooper3@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/mm/hap/nested_hap.c
> +++ b/xen/arch/x86/mm/hap/nested_hap.c
> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m,
> * walk is successful, the translated value is returned in
> * L1_gpa. The result value tells what to do next.
> */
> -static int
> +int
> nestedhap_walk_L1_p2m(struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa,
> unsigned int *page_order, uint8_t *p2m_acc,
The function becoming non-static widens the visibility of the bogus
uint8_t here (should be p2m_access_t afaics). Granted this isn't an
issue the patch introduces, but I would prefer this to be adjusted
prior to dropping the static here...
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2081,20 +2081,29 @@ unsigned long paging_gva_to_gfn(struct vcpu *v,
>
> if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) && nestedhvm_is_n2(v) )
> {
> - unsigned long gfn;
> + unsigned long l2_gfn, l1_gfn;
> struct p2m_domain *p2m;
> const struct paging_mode *mode;
> - uint32_t pfec_21 = *pfec;
> uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
> + uint8_t l1_p2ma;
... avoiding proliferation of the quirkiness.
> + unsigned int l1_page_order;
> + int rv;
>
> /* translate l2 guest va into l2 guest gfn */
> p2m = p2m_get_nestedp2m(v, np2m_base);
> mode = paging_get_nestedmode(v);
> - gfn = mode->gva_to_gfn(v, p2m, va, pfec);
> + l2_gfn = mode->gva_to_gfn(v, p2m, va, pfec);
> +
> + if ( l2_gfn == INVALID_GFN )
> + return INVALID_GFN;
>
> /* translate l2 guest gfn into l1 guest gfn */
> - return hostmode->p2m_ga_to_gfn(v, hostp2m, np2m_base,
> - gfn << PAGE_SHIFT, &pfec_21, NULL);
> + rv = nestedhap_walk_L1_p2m(v, l2_gfn, &l1_gfn, &l1_page_order,
> &l1_p2ma,
> + 1,
> + !!(*pfec & PFEC_write_access),
> + !!(*pfec & PFEC_insn_fetch));
> +
> + return rv == NESTEDHVM_PAGEFAULT_DONE ? l1_gfn : INVALID_GFN;
> }
I'm really happy to see this getting cleaned up - I've stumbled across
the apparent brokenness here more than once, without ever finding
the time to help the situation. One question though: Is the return
value here correct even for l1_page_order > 0?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |