|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 5/6] x86/hvm: Break out __hvm_copy()'s translation logic
>>> On 21.06.17 at 17:12, <andrew.cooper3@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3072,6 +3072,80 @@ void hvm_task_switch(
> hvm_unmap_entry(nptss_desc);
> }
>
> +enum hvm_translation_result hvm_translate_get_page(
> + struct vcpu *v, unsigned long addr, bool linear, uint32_t pfec,
> + pagefault_info_t *pfinfo, struct page_info **_page,
> + gfn_t *__gfn, p2m_type_t *_p2mt)
Please avoid leading underscores on parameter names (and even
more so double ones). page_p, gfn_p, and p2mt_p perhaps?
> +{
> + struct page_info *page;
> + p2m_type_t p2mt;
> + gfn_t gfn;
> +
> + if ( linear )
> + {
> + gfn = _gfn(paging_gva_to_gfn(v, addr, &pfec));
> +
> + if ( gfn_eq(gfn, INVALID_GFN) )
> + {
> + if ( pfec & PFEC_page_paged )
> + return HVMTRANS_gfn_paged_out;
> +
> + if ( pfec & PFEC_page_shared )
> + return HVMTRANS_gfn_shared;
> +
> + if ( pfinfo )
> + {
> + pfinfo->linear = addr;
> + pfinfo->ec = pfec & ~PFEC_implicit;
> + }
> +
> + return HVMTRANS_bad_linear_to_gfn;
> + }
> + }
> + else
> + gfn = _gfn(addr >> PAGE_SHIFT);
As we risk the caller not recognizing that *pfinfo won't be written
to on this "else" path, wouldn't it be a good idea to ASSERT(!pfinfo)
here?
> + /*
> + * No need to do the P2M lookup for internally handled MMIO, benefiting
> + * - 32-bit WinXP (& older Windows) on AMD CPUs for LAPIC accesses,
> + * - newer Windows (like Server 2012) for HPET accesses.
> + */
> + if ( v == current && is_hvm_vcpu(v)
Isn't the is_hvm_vcpu() a stray leftover from the PVHv1 removal,
and hence doesn't need retaining here?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |