* [PATCH v3] xen: support priv-mapping in an HVM tools domain
@ 2017-11-03 16:57 Paul Durrant
2017-11-03 16:59 ` Paul Durrant
0 siblings, 1 reply; 2+ messages in thread
From: Paul Durrant @ 2017-11-03 16:57 UTC (permalink / raw)
To: x86, xen-devel, linux-kernel
Cc: Paul Durrant, Boris Ostrovsky, Juergen Gross, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin
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>
v3:
- As v1 but with additional stubs in xen/xen-ops.h to handle
configurations without CONFIG_XEN_AUTO_XLATE.
---
arch/x86/xen/mmu.c | 14 ++++++++++++--
include/xen/xen-ops.h | 24 ++++++++++++++++++++++++
2 files changed, 36 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;
+
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);
+
/* 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;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 218e6aae5433..18b25631a113 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -103,6 +103,8 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
struct page **pages);
int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
int numpgs, struct page **pages);
+
+#ifdef CONFIG_XEN_AUTO_XLATE
int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
unsigned long addr,
xen_pfn_t *gfn, int nr,
@@ -111,6 +113,28 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
struct page **pages);
int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
int nr, struct page **pages);
+#else
+/*
+ * These two functions are called from arch/x86/xen/mmu.c and so stubs
+ * are needed for a configuration not specifying CONFIG_XEN_AUTO_XLATE.
+ */
+static inline int xen_xlate_remap_gfn_array(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)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
+ int nr, struct page **pages)
+{
+ return -EOPNOTSUPP;
+}
+#endif
+
int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
unsigned long nr_grant_frames);
--
2.11.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* RE: [PATCH v3] xen: support priv-mapping in an HVM tools domain
2017-11-03 16:57 [PATCH v3] xen: support priv-mapping in an HVM tools domain Paul Durrant
@ 2017-11-03 16:59 ` Paul Durrant
0 siblings, 0 replies; 2+ messages in thread
From: Paul Durrant @ 2017-11-03 16:59 UTC (permalink / raw)
To: Paul Durrant, x86, xen-devel, linux-kernel
Cc: Boris Ostrovsky, Juergen Gross, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin
> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 03 November 2017 16:58
> To: x86@kernel.org; xen-devel@lists.xenproject.org; linux-
> kernel@vger.kernel.org
> Cc: Paul Durrant <Paul.Durrant@citrix.com>; Boris Ostrovsky
> <boris.ostrovsky@oracle.com>; Juergen Gross <jgross@suse.com>; Thomas
> Gleixner <tglx@linutronix.de>; Ingo Molnar <mingo@redhat.com>; H. Peter
> Anvin <hpa@zytor.com>
> Subject: [PATCH v3] xen: support priv-mapping in an HVM tools domain
>
> 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.
<sigh> I realise now that this paragraph refers to the code in the v2 patch. I'll send v4.
Paul
>
> 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>
>
> v3:
> - As v1 but with additional stubs in xen/xen-ops.h to handle
> configurations without CONFIG_XEN_AUTO_XLATE.
> ---
> arch/x86/xen/mmu.c | 14 ++++++++++++--
> include/xen/xen-ops.h | 24 ++++++++++++++++++++++++
> 2 files changed, 36 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;
> +
> 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);
> +
> /* 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;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 218e6aae5433..18b25631a113 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -103,6 +103,8 @@ int xen_remap_domain_gfn_range(struct
> vm_area_struct *vma,
> struct page **pages);
> int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
> int numpgs, struct page **pages);
> +
> +#ifdef CONFIG_XEN_AUTO_XLATE
> int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> unsigned long addr,
> xen_pfn_t *gfn, int nr,
> @@ -111,6 +113,28 @@ int xen_xlate_remap_gfn_array(struct
> vm_area_struct *vma,
> struct page **pages);
> int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
> int nr, struct page **pages);
> +#else
> +/*
> + * These two functions are called from arch/x86/xen/mmu.c and so stubs
> + * are needed for a configuration not specifying
> CONFIG_XEN_AUTO_XLATE.
> + */
> +static inline int xen_xlate_remap_gfn_array(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)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
> + int nr, struct page **pages)
> +{
> + return -EOPNOTSUPP;
> +}
> +#endif
> +
> int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
> unsigned long nr_grant_frames);
>
> --
> 2.11.0
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-11-03 16:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-03 16:57 [PATCH v3] xen: support priv-mapping in an HVM tools domain Paul Durrant
2017-11-03 16:59 ` Paul Durrant
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).