All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <stefanos@xilinx.com>,
	julien.grall@arm.com, sstabellini@kernel.org,
	ian.jackson@eu.citrix.com, wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH v4 4/6] libxc: introduce xc_domain_mem_map_policy
Date: Tue,  6 Aug 2019 17:23:09 -0700	[thread overview]
Message-ID: <20190807002311.9906-4-sstabellini@kernel.org> (raw)
In-Reply-To: <alpine.DEB.2.21.1908061708420.2451@sstabellini-ThinkPad-T480s>

Introduce a new libxc function that makes use of the new memory_policy
parameter added to the XEN_DOMCTL_memory_mapping hypercall.

The parameter values are the same for the XEN_DOMCTL_memory_mapping
hypercall (0 is MEMORY_POLICY_DEFAULT). Pass MEMORY_POLICY_DEFAULT by
default -- no changes in behavior.

We could extend xc_domain_memory_mapping, but QEMU makes use of it, so
it is easier and less disruptive to introduce a new libxc function and
change the implementation of xc_domain_memory_mapping to call into it.

Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
CC: ian.jackson@eu.citrix.com
CC: wei.liu2@citrix.com
---
Changes in v2:
- rename cache_policy to memory policy
- rename MEMORY_POLICY_DEVMEM to MEMORY_POLICY_ARM_DEV_nGRE
- rename MEMORY_POLICY_MEMORY to MEMORY_POLICY_ARM_MEM_WB
- introduce xc_domain_mem_map_policy
---
 tools/libxc/include/xenctrl.h |  8 ++++++++
 tools/libxc/xc_domain.c       | 25 ++++++++++++++++++++-----
 2 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ff6ed9e70..2396929960 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1714,6 +1714,14 @@ int xc_deassign_dt_device(xc_interface *xch,
                           uint32_t domid,
                           char *path);
 
+int xc_domain_mem_map_policy(xc_interface *xch,
+                             uint32_t domid,
+                             unsigned long first_gfn,
+                             unsigned long first_mfn,
+                             unsigned long nr_mfns,
+                             uint32_t add_mapping,
+                             uint32_t memory_policy);
+
 int xc_domain_memory_mapping(xc_interface *xch,
                              uint32_t domid,
                              unsigned long first_gfn,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 075ffb9ed1..02f5778212 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2042,13 +2042,14 @@ failed:
     return -1;
 }
 
-int xc_domain_memory_mapping(
+int xc_domain_mem_map_policy(
     xc_interface *xch,
     uint32_t domid,
     unsigned long first_gfn,
     unsigned long first_mfn,
     unsigned long nr_mfns,
-    uint32_t add_mapping)
+    uint32_t add_mapping,
+    uint32_t memory_policy)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
@@ -2070,7 +2071,7 @@ int xc_domain_memory_mapping(
     domctl.cmd = XEN_DOMCTL_memory_mapping;
     domctl.domain = domid;
     domctl.u.memory_mapping.add_mapping = add_mapping;
-    domctl.u.memory_mapping.memory_policy = MEMORY_POLICY_DEFAULT;
+    domctl.u.memory_mapping.memory_policy = memory_policy;
     max_batch_sz = nr_mfns;
     do
     {
@@ -2106,8 +2107,9 @@ int xc_domain_memory_mapping(
      * Errors here are ignored.
      */
     if ( ret && add_mapping != DPCI_REMOVE_MAPPING )
-        xc_domain_memory_mapping(xch, domid, first_gfn, first_mfn, nr_mfns,
-                                 DPCI_REMOVE_MAPPING);
+        xc_domain_mem_map_policy(xch, domid, first_gfn, first_mfn, nr_mfns,
+                                 DPCI_REMOVE_MAPPING,
+                                 MEMORY_POLICY_DEFAULT);
 
     /* We might get E2BIG so many times that we never advance. */
     if ( !done && !ret )
@@ -2116,6 +2118,19 @@ int xc_domain_memory_mapping(
     return ret;
 }
 
+int xc_domain_memory_mapping(
+    xc_interface *xch,
+    uint32_t domid,
+    unsigned long first_gfn,
+    unsigned long first_mfn,
+    unsigned long nr_mfns,
+    uint32_t add_mapping)
+{
+    return xc_domain_mem_map_policy(xch, domid, first_gfn, first_mfn,
+                                    nr_mfns, add_mapping,
+                                    MEMORY_POLICY_DEFAULT);
+}
+
 int xc_domain_ioport_mapping(
     xc_interface *xch,
     uint32_t domid,
-- 
2.17.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2019-08-07  0:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07  0:23 [Xen-devel] [PATCH v4 0/6] iomem memory policy Stefano Stabellini
2019-08-07  0:23 ` [Xen-devel] [PATCH v4 1/6] xen/arm: introduce p2m_is_mmio Stefano Stabellini
2019-08-09 10:05   ` Julien Grall
2019-08-07  0:23 ` [Xen-devel] [PATCH v4 2/6] xen: add a p2mt parameter to map_mmio_regions Stefano Stabellini
2019-08-09 10:23   ` Julien Grall
2019-08-09 10:37     ` Jan Beulich
2019-08-09 10:51       ` Julien Grall
2019-08-09 11:07         ` Jan Beulich
2019-08-09 11:10   ` Jan Beulich
2019-08-07  0:23 ` [Xen-devel] [PATCH v4 3/6] xen: extend XEN_DOMCTL_memory_mapping to handle memory policy Stefano Stabellini
2019-08-09 11:25   ` Jan Beulich
2019-08-09 17:25   ` Julien Grall
2019-08-07  0:23 ` Stefano Stabellini [this message]
2019-08-07  0:23 ` [Xen-devel] [PATCH v4 5/6] libxl/xl: add memory policy option to iomem Stefano Stabellini
2019-08-09 17:23   ` Julien Grall
2019-08-07  0:23 ` [Xen-devel] [PATCH v4 6/6] xen/arm: clarify the support status of iomem configurations Stefano Stabellini
2019-08-07  9:08   ` Julien Grall
2019-08-07  9:16     ` Julien Grall

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=20190807002311.9906-4-sstabellini@kernel.org \
    --to=sstabellini@kernel.org \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien.grall@arm.com \
    --cc=stefanos@xilinx.com \
    --cc=wei.liu2@citrix.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.