From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753101AbdJSRnm (ORCPT ); Thu, 19 Oct 2017 13:43:42 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:21512 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753012AbdJSRnl (ORCPT ); Thu, 19 Oct 2017 13:43:41 -0400 Subject: Re: [PATCH] x86/xen: support priv-mapping in an HVM tools domain To: Paul Durrant , x86@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20171019152617.38463-1-paul.durrant@citrix.com> Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" From: Boris Ostrovsky Message-ID: <4e7e63a0-5a77-9dee-bbb7-dfa79c116fc8@oracle.com> Date: Thu, 19 Oct 2017 13:45:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20171019152617.38463-1-paul.durrant@citrix.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/19/2017 11:26 AM, Paul Durrant wrote: > If the domain has XENFEAT_auto_translated_physmap then use of the PV- > specific HYPERVISOR_mmu_update hypercall is clearly incorrect. > > This patch adds checks in xen_remap_domain_gfn_array() and > xen_unmap_domain_gfn_array() which call through to the approprate > xlate_mmu function if the feature is present. A check is also added > to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this > should not be used in an HVM tools domain. > > Signed-off-by: Paul Durrant > --- > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > --- > arch/x86/xen/mmu.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index 3e15345abfe7..d33e7dbe3129 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -172,6 +172,9 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma, > pgprot_t prot, unsigned domid, > struct page **pages) > { > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return -EOPNOTSUPP; > + This is never called on XENFEAT_auto_translated_physmap domains, there is a check in privcmd_ioctl_mmap() for that. > return do_remap_gfn(vma, addr, &gfn, nr, NULL, prot, domid, pages); > } > EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range); > @@ -182,6 +185,10 @@ int xen_remap_domain_gfn_array(struct vm_area_struct *vma, > int *err_ptr, pgprot_t prot, > unsigned domid, struct page **pages) > { > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return xen_xlate_remap_gfn_array(vma, addr, gfn, nr, err_ptr, > + prot, domid, pages); > + So how did this work before? In fact, I don't see any callers of xen_xlate_{re|un}map_gfn_range(). -boris > /* We BUG_ON because it's a programmer error to pass a NULL err_ptr, > * and the consequences later is quite hard to detect what the actual > * cause of "wrong memory was mapped in". > @@ -193,9 +200,12 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_array); > > /* Returns: 0 success */ > int xen_unmap_domain_gfn_range(struct vm_area_struct *vma, > - int numpgs, struct page **pages) > + int nr, struct page **pages) > { > - if (!pages || !xen_feature(XENFEAT_auto_translated_physmap)) > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return xen_xlate_unmap_gfn_range(vma, nr, pages); > + > + if (!pages) > return 0; > > return -EINVAL;