From: Juergen Gross <jgross@suse.com>
To: Paul Durrant <paul.durrant@citrix.com>,
x86@kernel.org, xen-devel@lists.xenproject.org,
linux-kernel@vger.kernel.org
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain
Date: Wed, 1 Nov 2017 14:39:31 +0100 [thread overview]
Message-ID: <a091b3ff-8140-e0b7-d118-0ce853e200df@suse.com> (raw)
In-Reply-To: <20171101113136.1844-1-paul.durrant@citrix.com>
On 01/11/17 12:31, 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.
>
> This patch also moves xen_remap_domain_gfn_range() into the PV-only MMU
> code and #ifdefs the (only) calling code in privcmd accordingly.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> ---
> arch/x86/xen/mmu.c | 36 +++++++++++++++++-------------------
> arch/x86/xen/mmu_pv.c | 11 +++++++++++
> drivers/xen/privcmd.c | 17 +++++++++++++----
> include/xen/xen-ops.h | 7 +++++++
> 4 files changed, 48 insertions(+), 23 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 3e15345abfe7..01837c36e293 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -91,12 +91,12 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> return 0;
> }
>
> -static int do_remap_gfn(struct vm_area_struct *vma,
> - unsigned long addr,
> - xen_pfn_t *gfn, int nr,
> - int *err_ptr, pgprot_t prot,
> - unsigned domid,
> - struct page **pages)
> +int xen_remap_gfn(struct vm_area_struct *vma,
> + unsigned long addr,
> + xen_pfn_t *gfn, int nr,
> + int *err_ptr, pgprot_t prot,
> + unsigned int domid,
> + struct page **pages)
> {
> int err = 0;
> struct remap_data rmd;
> @@ -166,36 +166,34 @@ static int do_remap_gfn(struct vm_area_struct *vma,
> return err < 0 ? err : mapped;
> }
>
> -int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
> - unsigned long addr,
> - xen_pfn_t gfn, int nr,
> - pgprot_t prot, unsigned domid,
> - struct page **pages)
> -{
> - return do_remap_gfn(vma, addr, &gfn, nr, NULL, prot, domid, pages);
> -}
> -EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
> -
> int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
> unsigned long addr,
> xen_pfn_t *gfn, int nr,
> 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);
> +
> /* 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".
> */
> BUG_ON(err_ptr == NULL);
> - return do_remap_gfn(vma, addr, gfn, nr, err_ptr, prot, domid, pages);
> + return xen_remap_gfn(vma, addr, gfn, nr, err_ptr, prot, domid,
> + pages);
> }
> 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;
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 71495f1a86d7..4974d8a6c2b4 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2670,3 +2670,14 @@ phys_addr_t paddr_vmcoreinfo_note(void)
> return __pa(vmcoreinfo_note);
> }
> #endif /* CONFIG_KEXEC_CORE */
> +
> +int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
> + unsigned long addr,
> + xen_pfn_t gfn, int nr,
> + pgprot_t prot, unsigned int domid,
> + struct page **pages)
> +{
> + return xen_remap_gfn(vma, addr, &gfn, nr, NULL, prot, domid,
> + pages);
> +}
> +EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index feca75b07fdd..b58a1719b606 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -215,6 +215,8 @@ static int traverse_pages_block(unsigned nelem, size_t size,
> return ret;
> }
>
> +#ifdef CONFIG_XEN_PV
> +
> struct mmap_gfn_state {
> unsigned long va;
> struct vm_area_struct *vma;
> @@ -261,10 +263,6 @@ static long privcmd_ioctl_mmap(struct file *file, void __user *udata)
> LIST_HEAD(pagelist);
> struct mmap_gfn_state state;
>
> - /* We only support privcmd_ioctl_mmap_batch for auto translated. */
> - if (xen_feature(XENFEAT_auto_translated_physmap))
> - return -ENOSYS;
> -
CONFIG_XEN_PV doesn't mean we don't support running as HVM guest.
I don't think you can remove this test, nor do I think it makes sense
to put privcmd_ioctl_mmap() inside an #ifdef.
You should rather add something like privcmd_ioctl_mmap_pv() with all
the PV-specific functionality and call this here. For !CONFIG_XEN_PV
it can e.g. just BUG().
Juergen
next prev parent reply other threads:[~2017-11-01 13:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 11:31 Paul Durrant
2017-11-01 13:39 ` Juergen Gross [this message]
2017-11-01 13:45 ` Paul Durrant
2017-11-01 15:37 ` Juergen Gross
2017-11-01 18:18 ` Boris Ostrovsky
2017-11-02 9:30 ` Paul Durrant
2017-11-02 20:59 ` Boris Ostrovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a091b3ff-8140-e0b7-d118-0ce853e200df@suse.com \
--to=jgross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paul.durrant@citrix.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®