All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v10 00/11] xen: better grant v2 support
@ 2017-09-25 10:00 Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 01/11] xen: add function for obtaining highest possible memory address Juergen Gross
                   ` (10 more replies)
  0 siblings, 11 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Currently Linux has no support for grant v2 as this would reduce the
maximum number of active grants by a factor of 2 compared to v1,
because the number of possible grants are limited by the allowed number
of grant frames and grant entries of v2 need twice as much bytes as
those of v1.

Unfortunately grant v2 is the only way to support either guests with
more than 16TB memory size or PV guests with memory above the 16TB
border, as grant v1 limits the frame number to be 32 bits wide.

In order to remove the disadvantage of grant v2 this patch series
adds support for setting per-domain values regarding grant limits.
Additionally the default limit of grant frames is doubled in case
of hosts with potential memory above the 16TB border.

Changes in V10:
- patch 1: avoid holes in xen_sysctl_physinfo, use uint64_aligned_t
  (Jan Beulich)
- patch 7: move locking into grant_table_init() (Jan Beulich)
- patch 9: lower INITIAL_NR_GRANT_FRAMES value to 1
- patch 9: removed no longer needed variables (Jan Beulich)
- patch 9: stream lined messages (Jan Beulich)
- patch 9: corrected setting of gnttab_size on ARM
- patch 10: correct comment in cpuid.h (Jan Beulich)
- added patch 11

Changes in V9:
- dropped the already committed patches 1-3
- merged former patches 4 and 5 (Jan Beulich)
- merged former patches 13 and 14
- patch 1: bump sysctl interface version (Julien Grall)
- patch 1: drop thin common shim of get_upper_mfn_bound() (Jan Beulich)
- patch 1: let get_upper_mfn_bound() return the highest MFN, not the one
  following it (Jan Beulich)
- patch 7: allocate initial grant frames from grant_table_init()
  (Jan Beulich)
- patch 8: correct and cleanup gnttab_init_arch() for ARM (Julien Grall)
- patch 10: make leaf pv-only (Jan Beulich)
- patch 10: use hex value for mask (Jan Beulich)
- patch 10: guest address width -> machine address width (Jan Beulich)

Changes in V8:
- dropped previous patch 1, as already committed
- patch 1: make gnttab_grow_table() static instead doing so in next
  patch (Jan Beulich)
- patch 3: remove stale #if 0, adjust comments (Paul Durrant)

Changes in V7:
- added patches 5, 6, 9, 16
- patch 2: only call gnttab_set_frame_gfn() if no error (Julien Grall)
- patch 10: don't use xc_maximum_ram_page() but max_possible_mfn from
   physinfo
- patch 13: re-add #include <asm/grant-table.h> in grant_table.h
  (Julien Grall)
- patch 15: add boot parameter documentation changes

Changes in V6:
- several new patches (1, 6, 7, 10, 12)
- order of patches re-arranged to support new hypercall now being
  mandatory
- lots of other small changes

Changes in V5:
- patch 6: add set_gnttab_limits to create_domain_common in xen.if
  (Daniel De Graaf)

Changes in V4:
- patch 3: make ret more local (Wei Liu)
- patch 7: use domid_t (Wei Liu)
- patch 8: rename configuration items to use max_ prefixes (Wei Liu)

Changes in V3:
- patch 1: update commit message
- patch 3: move call of grant_table_init() from gnttab_setup_table() to
  gnttab_grow_table() (Paul Durrant)
- patch 4: correct error message (Paul Durrant)
- patch 6: rename *gnttbl* to *gnttab* (Paul Durrant)

Changes in V2:
- add per-domain grant limits instead of different v1 and v2 limits
- double default limit for huge hosts

Juergen Gross (11):
  xen: add function for obtaining highest possible memory address
  libxc: add libxc support for setting grant table resource limits
  tools: set grant limits for xenstore stubdom
  libxl: add max possible mfn to libxl_physinfo
  xl: add global grant limit config items
  libxl: add libxl support for setting grant table resource limits
  xen: delay allocation of grant table sub structures
  xen/arm: move arch specific grant table bits into grant_table.c
  xen: make grant resource limits per domain
  xen: add new Xen cpuid node for max address width info
  xen: add some comments in include/public/arch-x86/cpuid.h

 docs/man/xl.cfg.pod.5.in             |  16 ++
 docs/man/xl.conf.pod.5               |  12 ++
 docs/misc/xen-command-line.markdown  |  25 +--
 tools/helpers/init-xenstore-domain.c |  11 ++
 tools/libxc/include/xenctrl.h        |  13 ++
 tools/libxc/xc_domain.c              |  13 ++
 tools/libxl/libxl.c                  |   1 +
 tools/libxl/libxl.h                  |  15 ++
 tools/libxl/libxl_dm.c               |   3 +
 tools/libxl/libxl_dom.c              |   6 +
 tools/libxl/libxl_types.idl          |   4 +
 tools/xl/xl.c                        |  15 ++
 tools/xl/xl.h                        |   2 +
 tools/xl/xl_parse.c                  |   9 ++
 tools/xl/xl_sxp.c                    |   2 +
 xen/arch/arm/domain.c                |   2 -
 xen/arch/arm/domain_build.c          |   6 +-
 xen/arch/arm/mm.c                    |   6 +
 xen/arch/x86/mm.c                    |  11 ++
 xen/arch/x86/traps.c                 |   7 +
 xen/common/compat/grant_table.c      |  31 +---
 xen/common/grant_table.c             | 286 ++++++++++++++++++++---------------
 xen/common/sysctl.c                  |   1 +
 xen/include/asm-arm/domain.h         |   1 -
 xen/include/asm-arm/grant_table.h    |  34 ++++-
 xen/include/asm-x86/grant_table.h    |  19 ++-
 xen/include/public/arch-x86/cpuid.h  |  31 +++-
 xen/include/public/sysctl.h          |   7 +-
 xen/include/xen/grant_table.h        |   5 +-
 xen/include/xen/mm.h                 |   3 +
 30 files changed, 410 insertions(+), 187 deletions(-)

-- 
2.12.3


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v10 01/11] xen: add function for obtaining highest possible memory address
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 10:19   ` Jan Beulich
  2017-09-28  0:29   ` Julien Grall
  2017-09-25 10:00 ` [PATCH v10 02/11] libxc: add libxc support for setting grant table resource limits Juergen Gross
                   ` (9 subsequent siblings)
  10 siblings, 2 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Add a function for obtaining the highest possible physical memory
address of the system. This value is influenced by:

- hypervisor configuration (CONFIG_BIGMEM)
- processor capability (max. addressable physical memory)
- memory map at boot time
- memory hotplug capability

Add this value to xen_sysctl_physinfo in order to enable dom0 to do a
proper sizing of grant frame limits of guests.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
V10:
- avoid holes in xen_sysctl_physinfo, use uint64_aligned_t
  (Jan Beulich)

V9:
- merge patch with following one (Jan Beulich)
- bump sysctl interface version (Julien Grall)
- drop thin common shim of get_upper_mfn_bound() (Jan Beulich)
- let get_upper_mfn_bound() return the highest MFN, not the one
  following it (Jan Beulich)
---
 xen/arch/arm/mm.c           |  6 ++++++
 xen/arch/x86/mm.c           | 11 +++++++++++
 xen/common/sysctl.c         |  1 +
 xen/include/public/sysctl.h |  7 ++++---
 xen/include/xen/mm.h        |  3 +++
 5 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f3834b3dab..9a37f29ce6 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1472,6 +1472,12 @@ void clear_and_clean_page(struct page_info *page)
     unmap_domain_page(p);
 }
 
+unsigned long get_upper_mfn_bound(void)
+{
+    /* No memory hotplug yet, so current memory limit is the final one. */
+    return max_page - 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index afd5a101a4..d9df5ca69f 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5178,6 +5178,17 @@ void write_32bit_pse_identmap(uint32_t *l2)
                  _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
 }
 
+unsigned long get_upper_mfn_bound(void)
+{
+    unsigned long max_mfn;
+
+    max_mfn = mem_hotplug ? PFN_DOWN(mem_hotplug) : max_page;
+#ifndef CONFIG_BIGMEM
+    max_mfn = min(max_mfn, 1UL << 32);
+#endif
+    return min(max_mfn, 1UL << (paddr_bits - PAGE_SHIFT)) - 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 3480f582fa..08198b7150 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -266,6 +266,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         get_outstanding_claims(&pi->free_pages, &pi->outstanding_pages);
         pi->scrub_pages = 0;
         pi->cpu_khz = cpu_khz;
+        pi->max_mfn = get_upper_mfn_bound();
         arch_do_physinfo(pi);
 
         if ( copy_to_guest(u_sysctl, op, 1) )
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 4d32a87cca..1e6097584b 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -36,7 +36,7 @@
 #include "physdev.h"
 #include "tmem.h"
 
-#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000F
+#define XEN_SYSCTL_INTERFACE_VERSION 0x00000010
 
 /*
  * Read console content from Xen buffer ring.
@@ -96,14 +96,15 @@ struct xen_sysctl_physinfo {
     uint32_t nr_nodes;    /* # nodes currently online */
     uint32_t max_node_id; /* Largest possible node ID on this host */
     uint32_t cpu_khz;
+    uint32_t capabilities; /* XEN_SYSCTL_PHYSCAP_??? */
+
     uint64_aligned_t total_pages;
     uint64_aligned_t free_pages;
     uint64_aligned_t scrub_pages;
     uint64_aligned_t outstanding_pages;
     uint32_t hw_cap[8];
 
-    /* XEN_SYSCTL_PHYSCAP_??? */
-    uint32_t capabilities;
+    uint64_aligned_t max_mfn; /* Largest possible MFN on this host */
 };
 
 /*
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index f8b6177c32..e813c07b22 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -599,6 +599,9 @@ int prepare_ring_for_helper(struct domain *d, unsigned long gmfn,
                             struct page_info **_page, void **_va);
 void destroy_ring_for_helper(void **_va, struct page_info *page);
 
+/* Return the upper bound of MFNs, including hotplug memory. */
+unsigned long get_upper_mfn_bound(void);
+
 #include <asm/flushtlb.h>
 
 static inline void accumulate_tlbflush(bool *need_tlbflush,
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 02/11] libxc: add libxc support for setting grant table resource limits
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 01/11] xen: add function for obtaining highest possible memory address Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 03/11] tools: set grant limits for xenstore stubdom Juergen Gross
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Add a new libxc function xc_domain_set_gnttbl_limits() setting the
limits for the maximum numbers of grant table frames and maptrack
frames of a domain.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
V4:
- use domid_t (Wei Liu)
---
 tools/libxc/include/xenctrl.h | 13 +++++++++++++
 tools/libxc/xc_domain.c       | 13 +++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 073fbc9b08..182367e7f4 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1064,6 +1064,19 @@ int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t domid,
                              uint32_t max_port);
 
+/**
+ * Set the maximum number of grant frames and maptrack frames a domain
+ * can have. Must be used at domain setup time and only then.
+ *
+ * @param xch a handle to an open hypervisor interface
+ * @param domid the domain id
+ * @param grant_frames max. number of grant frames
+ * @param maptrack_frames max. number of maptrack frames
+ */
+int xc_domain_set_gnttab_limits(xc_interface *xch, domid_t domid,
+                                uint32_t grant_frames,
+                                uint32_t maptrack_frames);
+
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
  */
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index f40dc4fd7b..4a7078008f 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2266,6 +2266,19 @@ int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t domid,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_gnttab_limits(xc_interface *xch, domid_t domid,
+                                uint32_t grant_frames,
+                                uint32_t maptrack_frames)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_gnttab_limits;
+    domctl.domain = domid;
+    domctl.u.set_gnttab_limits.grant_frames = grant_frames;
+    domctl.u.set_gnttab_limits.maptrack_frames = maptrack_frames;
+    return do_domctl(xch, &domctl);
+}
+
 /* Plumbing Xen with vNUMA topology */
 int xc_domain_setvnuma(xc_interface *xch,
                        uint32_t domid,
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 03/11] tools: set grant limits for xenstore stubdom
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 01/11] xen: add function for obtaining highest possible memory address Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 02/11] libxc: add libxc support for setting grant table resource limits Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 04/11] libxl: add max possible mfn to libxl_physinfo Juergen Gross
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

When creating a Xenstore stubdom set the grant limits: the stubdom
will need to setup a very limited amount of grants only, so 4 grant
frames are enough. For being able to support up to 32768 domains it
will need 128 maptrack frames (1 mapping per domain, 256 maptrack
entries per maptrack frame).

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/helpers/init-xenstore-domain.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c
index 8a41ee7d3a..047ad0cb1d 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -105,6 +105,17 @@ static int build(xc_interface *xch)
         fprintf(stderr, "xc_domain_setmaxmem failed\n");
         goto err;
     }
+    /*
+     * 1 grant frame is enough: we don't need many grants.
+     * Mini-OS doesn't like less than 4, though, so use 4.
+     * 128 maptrack frames: 256 entries per frame, enough for 32768 domains.
+     */
+    rv = xc_domain_set_gnttab_limits(xch, domid, 4, 128);
+    if ( rv )
+    {
+        fprintf(stderr, "xc_domain_set_gnttab_limits failed\n");
+        goto err;
+    }
     rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
     if ( rv )
     {
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 04/11] libxl: add max possible mfn to libxl_physinfo
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
                   ` (2 preceding siblings ...)
  2017-09-25 10:00 ` [PATCH v10 03/11] tools: set grant limits for xenstore stubdom Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 05/11] xl: add global grant limit config items Juergen Gross
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Add the maximum possible mfn of the host to the libxl_physinfo
data structure.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c         | 1 +
 tools/libxl/libxl.h         | 9 +++++++++
 tools/libxl/libxl_types.idl | 1 +
 3 files changed, 11 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 247c56cf83..b41ade9fda 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -373,6 +373,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
     physinfo->outstanding_pages = xcphysinfo.outstanding_pages;
+    physinfo->max_possible_mfn = xcphysinfo.max_mfn;
     l = xc_sharing_freed_pages(ctx->xch);
     if (l < 0 && errno == ENOSYS) {
         l = 0;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7d853ca924..fb960debee 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -644,6 +644,15 @@ typedef struct libxl__ctx libxl_ctx;
 #define LIBXL_HAVE_PHYSINFO_OUTSTANDING_PAGES 1
 
 /*
+ * LIBXL_HAVE_PHYSINFO_MAX_POSSIBLE_MFN
+ *
+ * If this is defined, libxl_physinfo structure will contain an uint64 field
+ * called max_possible_mfn, containing the highest possible mfn on this host,
+ * possibly taking memory hotplug into account.
+ */
+#define LIBXL_HAVE_PHYSINFO_MAX_POSSIBLE_MFN 1
+
+/*
  * LIBXL_HAVE_DOMINFO_OUTSTANDING_MEMKB 1
  *
  * If this is defined, libxl_dominfo will contain a MemKB type field called
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 756e120ad7..5d9e7aabba 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -895,6 +895,7 @@ libxl_physinfo = Struct("physinfo", [
     ("outstanding_pages", uint64),
     ("sharing_freed_pages", uint64),
     ("sharing_used_frames", uint64),
+    ("max_possible_mfn", uint64),
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 05/11] xl: add global grant limit config items
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
                   ` (3 preceding siblings ...)
  2017-09-25 10:00 ` [PATCH v10 04/11] libxl: add max possible mfn to libxl_physinfo Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 06/11] libxl: add libxl support for setting grant table resource limits Juergen Gross
                   ` (5 subsequent siblings)
  10 siblings, 0 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Add xl.conf config items for default values of grant limits:

max_grant_frames will set the default for the maximum number of grant
frames for a domain which will take effect if the domain's config file
doesn't specify a value. If max_grant_frames isn't set in xl.conf it
will default to 32 for hosts with all memory below 16TB and to 64 for
hosts with memory above 16TB.

max_maptrack_frames will set the default for the maximum number of
maptrack frames for a domain. If max_maptrack_frames isn't set in
xl.conf it will default to 0, as normally only backend domains need
maptrack frames.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
V7:
- don't use xc_maximum_ram_page() but max_possible_mfn from physinfo
---
 docs/man/xl.conf.pod.5 | 12 ++++++++++++
 tools/xl/xl.c          | 15 +++++++++++++++
 tools/xl/xl.h          |  2 ++
 3 files changed, 29 insertions(+)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 88ab506609..fe2cf27ea4 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -77,6 +77,18 @@ operations (primarily domain creation).
 
 Default: C</var/lock/xl>
 
+=item B<max_grant_frames=NUMBER>
+
+Sets the default value for the C<max_grant_frames> domain config value.
+
+Default: C<32> on hosts up to 16TB of memory, C<64> on hosts larger than 16TB
+
+=item B<max_maptrack_frames=NUMBER>
+
+Sets the default value for the C<max_maptrack_frames> domain config value.
+
+Default: C<0>
+
 =item B<vif.default.script="PATH">
 
 Configures the default hotplug script used by virtual network devices.
diff --git a/tools/xl/xl.c b/tools/xl/xl.c
index 02179a6229..c1bbb4b939 100644
--- a/tools/xl/xl.c
+++ b/tools/xl/xl.c
@@ -45,6 +45,8 @@ char *default_colo_proxy_script = NULL;
 enum output_format default_output_format = OUTPUT_FORMAT_JSON;
 int claim_mode = 1;
 bool progress_use_cr = 0;
+int max_grant_frames = -1;
+int max_maptrack_frames = 0;
 
 xentoollog_level minmsglevel = minmsglevel_default;
 
@@ -88,6 +90,7 @@ static void parse_global_config(const char *configfile,
     XLU_Config *config;
     int e;
     const char *buf;
+    libxl_physinfo physinfo;
 
     config = xlu_cfg_init(stderr, configfile);
     if (!config) {
@@ -188,6 +191,18 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_replace_string (config, "colo.default.proxyscript",
         &default_colo_proxy_script, 0);
 
+    if (!xlu_cfg_get_long (config, "max_grant_frames", &l, 0))
+        max_grant_frames = l;
+    else {
+        libxl_physinfo_init(&physinfo);
+        max_grant_frames = (libxl_get_physinfo(ctx, &physinfo) != 0 ||
+                            !(physinfo.max_possible_mfn >> 32))
+                           ? 32 : 64;
+        libxl_physinfo_dispose(&physinfo);
+    }
+    if (!xlu_cfg_get_long (config, "max_maptrack_frames", &l, 0))
+        max_maptrack_frames = l;
+
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 31d660b89a..6b60d1db50 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -275,6 +275,8 @@ extern char *default_vifbackend;
 extern char *default_remus_netbufscript;
 extern char *default_colo_proxy_script;
 extern char *blkdev_start;
+extern int max_grant_frames;
+extern int max_maptrack_frames;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 06/11] libxl: add libxl support for setting grant table resource limits
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
                   ` (4 preceding siblings ...)
  2017-09-25 10:00 ` [PATCH v10 05/11] xl: add global grant limit config items Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 07/11] xen: delay allocation of grant table sub structures Juergen Gross
                   ` (4 subsequent siblings)
  10 siblings, 0 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Add new domain config items for setting the limits for the maximum
numbers of grant table frames and maptrack frames of a domain.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
V6:
- made set_gnttab_limits hypercall mandatory, taking defaults from
  xl.conf

V4:
- rename configuration items to use max_ prefixes (Wei Liu)
---
 docs/man/xl.cfg.pod.5.in    | 16 ++++++++++++++++
 tools/libxl/libxl.h         |  6 ++++++
 tools/libxl/libxl_dm.c      |  3 +++
 tools/libxl/libxl_dom.c     |  6 ++++++
 tools/libxl/libxl_types.idl |  3 +++
 tools/xl/xl_parse.c         |  9 +++++++++
 tools/xl/xl_sxp.c           |  2 ++
 7 files changed, 45 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 247ae99ca7..e7ab67395b 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -444,6 +444,20 @@ unpausing the domain. With a properly constructed security policy (such
 as nomigrate_t in the example policy), this can be used to build a
 domain whose memory is not accessible to the toolstack domain.
 
+=item B<max_grant_frames=NUMBER>
+
+Specify the maximum number of grant frames the domain is allowed to have.
+This value controls how many pages the domain is able to grant access to for
+other domains, needed e.g. for the operation of paravirtualized devices.
+The default is settable via L<xl.conf(5)>.
+
+=item B<max_maptrack_frames=NUMBER>
+
+Specify the maximum number of grant maptrack frames the domain is allowed
+to have. This value controls how many pages of foreign domains can be accessed
+via the grant mechanism by this domain. The default value is settable via
+L<xl.conf(5)>.
+
 =item B<nomigrate=BOOLEAN>
 
 Disable migration of this domain.  This enables certain other features
@@ -2252,6 +2266,8 @@ No MCA capabilities in above list are enabled.
 
 =item L<xl(1)>
 
+=item L<xl.conf(5)>
+
 =item L<xlcpupool.cfg(5)>
 
 =item L<xl-disk-configuration(5)>
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index fb960debee..c6f42945de 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -311,6 +311,12 @@
 #define LIBXL_HAVE_P9S 1
 
 /*
+ * LIBXL_HAVE_BUILDINFO_GRANT_LIMITS indicates that libxl_domain_build_info
+ * has the max_grant_frames and max_maptrack_frames fields.
+ */
+#define LIBXL_HAVE_BUILDINFO_GRANT_LIMITS 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 98f89a95ce..bf651006b4 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1845,6 +1845,9 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
         guest_config->b_info.video_memkb;
     dm_config->b_info.target_memkb = dm_config->b_info.max_memkb;
 
+    dm_config->b_info.max_grant_frames = guest_config->b_info.max_grant_frames;
+    dm_config->b_info.max_maptrack_frames = 0;
+
     dm_config->b_info.u.pv.features = "";
 
     dm_config->b_info.device_model_version =
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f54fd49a73..b420738adf 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -322,6 +322,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         return ERROR_FAIL;
     }
 
+    if (xc_domain_set_gnttab_limits(ctx->xch, domid, info->max_grant_frames,
+                                    info->max_maptrack_frames) != 0) {
+        LOG(ERROR, "Couldn't set grant table limits");
+        return ERROR_FAIL;
+    }
+
     /*
      * Check if the domain has any CPU or node affinity already. If not, try
      * to build up the latter via automatic NUMA placement. In fact, in case
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 5d9e7aabba..dc3544873c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -472,6 +472,9 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("blkdev_start",    string),
 
     ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
+
+    ("max_grant_frames",    uint32),
+    ("max_maptrack_frames", uint32),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 0678fbc1b0..5ba18e9a15 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -990,6 +990,15 @@ void parse_config_data(const char *config_source,
         !xlu_cfg_get_string (config, "cpus_soft", &buf, 0))
         parse_vcpu_affinity(b_info, cpus, buf, num_cpus, false);
 
+    if (!xlu_cfg_get_long (config, "max_grant_frames", &l, 0))
+        b_info->max_grant_frames = l;
+    else
+        b_info->max_grant_frames = max_grant_frames;
+    if (!xlu_cfg_get_long (config, "max_maptrack_frames", &l, 0))
+        b_info->max_maptrack_frames = l;
+    else
+        b_info->max_maptrack_frames = max_maptrack_frames;
+
     libxl_defbool_set(&b_info->claim_mode, claim_mode);
 
     if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
diff --git a/tools/xl/xl_sxp.c b/tools/xl/xl_sxp.c
index e738bf2465..e264cf2023 100644
--- a/tools/xl/xl_sxp.c
+++ b/tools/xl/xl_sxp.c
@@ -64,6 +64,8 @@ void printf_info_sexp(int domid, libxl_domain_config *d_config, FILE *fh)
 
     fprintf(fh, "\t(build_info)\n");
     fprintf(fh, "\t(max_vcpus %d)\n", b_info->max_vcpus);
+    fprintf(fh, "\t(max_grant_frames %d)\n", b_info->max_grant_frames);
+    fprintf(fh, "\t(max_maptrack_frames %d)\n", b_info->max_maptrack_frames);
     fprintf(fh, "\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     fprintf(fh, "\t(max_memkb %"PRId64")\n", b_info->max_memkb);
     fprintf(fh, "\t(target_memkb %"PRId64")\n", b_info->target_memkb);
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 07/11] xen: delay allocation of grant table sub structures
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
                   ` (5 preceding siblings ...)
  2017-09-25 10:00 ` [PATCH v10 06/11] libxl: add libxl support for setting grant table resource limits Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 10:16   ` Jan Beulich
  2017-09-28 18:56   ` Andrew Cooper
  2017-09-25 10:00 ` [PATCH v10 08/11] xen/arm: move arch specific grant table bits into grant_table.c Juergen Gross
                   ` (3 subsequent siblings)
  10 siblings, 2 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Delay the allocation of the grant table sub structures in order to
allow modifying parameters needed for sizing of these structures at a
per domain basis. Allocate the structures and the table frames only
from grant_table_init().

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
---
V10:
- move locking into grant_table_init() (Jan Beulich)

V9:
- allocate initial grant frames from grant_table_init() (Jan Beulich)

V6:
- move call of grant_table_init() for dom0 to grant_table_create()
  (Jan Beulich)
- move frame allocations to gnttab_grow_table() (Jan Beulich)
- several other changes due to new patch order

V4:
- make ret more local (Wei Liu)

V3:
- move call of grant_table_init() from gnttab_setup_table() to
  gnttab_grow_table() (Paul Durrant)
---
 xen/common/grant_table.c | 134 +++++++++++++++++++++++------------------------
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0f09891f59..d86a4e0248 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1667,6 +1667,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
     struct grant_table *gt = d->grant_table;
     unsigned int i, j;
 
+    ASSERT(gt->active);
+
+    if ( req_nr_frames < INITIAL_NR_GRANT_FRAMES )
+        req_nr_frames = INITIAL_NR_GRANT_FRAMES;
     ASSERT(req_nr_frames <= max_grant_frames);
 
     gdprintk(XENLOG_INFO,
@@ -1723,6 +1727,60 @@ active_alloc_failed:
     return 0;
 }
 
+static int
+grant_table_init(struct domain *d, struct grant_table *gt)
+{
+    int ret = 0;
+
+    grant_write_lock(gt);
+
+    if ( gt->active )
+    {
+        ret = -EBUSY;
+        goto unlock;
+    }
+
+    /* Active grant table. */
+    gt->active = xzalloc_array(struct active_grant_entry *,
+                               max_nr_active_grant_frames);
+    if ( gt->active == NULL )
+        goto no_mem;
+
+    /* Tracking of mapped foreign frames table */
+    gt->maptrack = vzalloc(max_maptrack_frames * sizeof(*gt->maptrack));
+    if ( gt->maptrack == NULL )
+        goto no_mem;
+
+    /* Shared grant table. */
+    gt->shared_raw = xzalloc_array(void *, max_grant_frames);
+    if ( gt->shared_raw == NULL )
+        goto no_mem;
+
+    /* Status pages for grant table - for version 2 */
+    gt->status = xzalloc_array(grant_status_t *,
+                               grant_to_status_frames(max_grant_frames));
+    if ( gt->status == NULL )
+        goto no_mem;
+
+    /* gnttab_grow_table() allocates a min number of frames, so 0 is okay. */
+    if ( gnttab_grow_table(d, 0) )
+        goto unlock;
+
+ no_mem:
+    ret = -ENOMEM;
+    xfree(gt->shared_raw);
+    gt->shared_raw = NULL;
+    vfree(gt->maptrack);
+    gt->maptrack = NULL;
+    xfree(gt->active);
+    gt->active = NULL;
+
+ unlock:
+    grant_write_unlock(gt);
+
+    return ret;
+}
+
 static long
 gnttab_setup_table(
     XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
@@ -3383,75 +3441,24 @@ grant_table_create(
     struct domain *d)
 {
     struct grant_table *t;
-    unsigned int i, j;
+    int ret = 0;
 
     if ( (t = xzalloc(struct grant_table)) == NULL )
-        goto no_mem_0;
+        return -ENOMEM;
 
     /* Simple stuff. */
     percpu_rwlock_resource_init(&t->lock, grant_rwlock);
     spin_lock_init(&t->maptrack_lock);
-    t->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
-
-    /* Active grant table. */
-    if ( (t->active = xzalloc_array(struct active_grant_entry *,
-                                    max_nr_active_grant_frames)) == NULL )
-        goto no_mem_1;
-    for ( i = 0;
-          i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
-    {
-        if ( (t->active[i] = alloc_xenheap_page()) == NULL )
-            goto no_mem_2;
-        clear_page(t->active[i]);
-        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
-            spin_lock_init(&t->active[i][j].lock);
-    }
 
-    /* Tracking of mapped foreign frames table */
-    t->maptrack = vzalloc(max_maptrack_frames * sizeof(*t->maptrack));
-    if ( t->maptrack == NULL )
-        goto no_mem_2;
+    /* Okay, install the structure. */
+    d->grant_table = t;
 
-    /* Shared grant table. */
-    if ( (t->shared_raw = xzalloc_array(void *, max_grant_frames)) == NULL )
-        goto no_mem_3;
-    for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+    if ( d->domain_id == 0 )
     {
-        if ( (t->shared_raw[i] = alloc_xenheap_page()) == NULL )
-            goto no_mem_4;
-        clear_page(t->shared_raw[i]);
+        ret = grant_table_init(d, t);
     }
 
-    /* Status pages for grant table - for version 2 */
-    t->status = xzalloc_array(grant_status_t *,
-                              grant_to_status_frames(max_grant_frames));
-    if ( t->status == NULL )
-        goto no_mem_4;
-
-    for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
-        gnttab_create_shared_page(d, t, i);
-
-    t->nr_status_frames = 0;
-
-    /* Okay, install the structure. */
-    d->grant_table = t;
-    return 0;
-
- no_mem_4:
-    for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
-        free_xenheap_page(t->shared_raw[i]);
-    xfree(t->shared_raw);
- no_mem_3:
-    vfree(t->maptrack);
- no_mem_2:
-    for ( i = 0;
-          i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
-        free_xenheap_page(t->active[i]);
-    xfree(t->active);
- no_mem_1:
-    xfree(t);
- no_mem_0:
-    return -ENOMEM;
+    return ret;
 }
 
 void
@@ -3646,19 +3653,12 @@ int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
                            unsigned int maptrack_frames)
 {
     struct grant_table *gt = d->grant_table;
-    int ret = -EBUSY;
 
     if ( !gt )
         return -ENOENT;
 
-    grant_write_lock(gt);
-
-    ret = 0;
-    /* Set limits, alloc needed arrays. */
-
-    grant_write_unlock(gt);
-
-    return ret;
+    /* Set limits. */
+    return grant_table_init(d, gt);
 }
 
 #ifdef CONFIG_HAS_MEM_SHARING
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 08/11] xen/arm: move arch specific grant table bits into grant_table.c
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
                   ` (6 preceding siblings ...)
  2017-09-25 10:00 ` [PATCH v10 07/11] xen: delay allocation of grant table sub structures Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-28  0:31   ` Julien Grall
  2017-09-25 10:00 ` [PATCH v10 09/11] xen: make grant resource limits per domain Juergen Gross
                   ` (2 subsequent siblings)
  10 siblings, 1 reply; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Instead of attaching the ARM specific grant table data to the domain
structure add it to struct grant_table. Add the needed arch functions
to the asm-*/grant_table.h includes.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com> [non-ARM parts]
---
V9:
- correct and cleanup gnttab_init_arch() for ARM (Julien Grall)

V7:
- re-add #include <asm/grant-table.h> in grant_table.h (Julien Grall)
---
 xen/arch/arm/domain.c             |  2 --
 xen/common/grant_table.c          | 16 ++++++++++++++--
 xen/include/asm-arm/domain.h      |  1 -
 xen/include/asm-arm/grant_table.h | 29 ++++++++++++++++++++++-------
 xen/include/asm-x86/grant_table.h | 12 +++++++-----
 xen/include/xen/grant_table.h     |  2 ++
 6 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 784ae392cf..e39a79885c 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -486,13 +486,11 @@ struct domain *alloc_domain_struct(void)
         return NULL;
 
     clear_page(d);
-    d->arch.grant_table_gfn = xzalloc_array(gfn_t, max_grant_frames);
     return d;
 }
 
 void free_domain_struct(struct domain *d)
 {
-    xfree(d->arch.grant_table_gfn);
     free_xenheap_page(d);
 }
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index d86a4e0248..71706f5cba 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -72,6 +72,8 @@ struct grant_table {
     struct active_grant_entry **active;
     /* Mapping tracking table per vcpu. */
     struct grant_mapping **maptrack;
+
+    struct grant_table_arch arch;
 };
 
 #ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
@@ -1730,7 +1732,7 @@ active_alloc_failed:
 static int
 grant_table_init(struct domain *d, struct grant_table *gt)
 {
-    int ret = 0;
+    int ret;
 
     grant_write_lock(gt);
 
@@ -1762,12 +1764,20 @@ grant_table_init(struct domain *d, struct grant_table *gt)
     if ( gt->status == NULL )
         goto no_mem;
 
+    ret = gnttab_init_arch(gt);
+    if ( ret )
+        goto out;
+
     /* gnttab_grow_table() allocates a min number of frames, so 0 is okay. */
     if ( gnttab_grow_table(d, 0) )
         goto unlock;
 
  no_mem:
     ret = -ENOMEM;
+ out:
+    gnttab_destroy_arch(gt);
+    xfree(gt->status);
+    gt->status = NULL;
     xfree(gt->shared_raw);
     gt->shared_raw = NULL;
     vfree(gt->maptrack);
@@ -3622,6 +3632,8 @@ grant_table_destroy(
     if ( t == NULL )
         return;
 
+    gnttab_destroy_arch(t);
+
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
     xfree(t->shared_raw);
@@ -3740,7 +3752,7 @@ int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
     }
 
     if ( !rc )
-        gnttab_set_frame_gfn(d, idx, gfn);
+        gnttab_set_frame_gfn(gt, idx, gfn);
 
     grant_write_unlock(gt);
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index b174c65080..ce9b6a4032 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -50,7 +50,6 @@ struct arch_domain
     struct p2m_domain p2m;
 
     struct hvm_domain hvm_domain;
-    gfn_t *grant_table_gfn;
 
     struct vmmio vmmio;
 
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
index 0a248a765a..30db2d1616 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -6,6 +6,10 @@
 
 #define INITIAL_NR_GRANT_FRAMES 4
 
+struct grant_table_arch {
+    gfn_t *gfn;
+};
+
 void gnttab_clear_flag(unsigned long nr, uint16_t *addr);
 int create_grant_host_mapping(unsigned long gpaddr,
         unsigned long mfn, unsigned int flags, unsigned int
@@ -22,11 +26,22 @@ static inline int replace_grant_supported(void)
     return 1;
 }
 
-static inline void gnttab_set_frame_gfn(struct domain *d, unsigned long idx,
-                                        gfn_t gfn)
-{
-    d->arch.grant_table_gfn[idx] = gfn;
-}
+#define gnttab_init_arch(gt)                                             \
+({                                                                       \
+    (gt)->arch.gfn = xzalloc_array(gfn_t, max_grant_frames);             \
+    ( (gt)->arch.gfn ? 0 : -ENOMEM );                                    \
+})
+
+#define gnttab_destroy_arch(gt)                                          \
+    do {                                                                 \
+        xfree((gt)->arch.gfn);                                           \
+        (gt)->arch.gfn = NULL;                                           \
+    } while ( 0 )
+
+#define gnttab_set_frame_gfn(gt, idx, gfn)                               \
+    do {                                                                 \
+        (gt)->arch.gfn[idx] = gfn;                                       \
+    } while ( 0 )
 
 #define gnttab_create_shared_page(d, t, i)                               \
     do {                                                                 \
@@ -36,8 +51,8 @@ static inline void gnttab_set_frame_gfn(struct domain *d, unsigned long idx,
     } while ( 0 )
 
 #define gnttab_shared_gmfn(d, t, i)                                      \
-    ( ((i >= nr_grant_frames(d->grant_table)) &&                         \
-     (i < max_grant_frames)) ? 0 : gfn_x(d->arch.grant_table_gfn[i]))
+    ( ((i >= nr_grant_frames(t)) &&                                      \
+       (i < max_grant_frames)) ? 0 : gfn_x(t->arch.gfn[i]))
 
 #define gnttab_need_iommu_mapping(d)                    \
     (is_domain_direct_mapped(d) && need_iommu(d))
diff --git a/xen/include/asm-x86/grant_table.h b/xen/include/asm-x86/grant_table.h
index c865999a33..1b93c5720d 100644
--- a/xen/include/asm-x86/grant_table.h
+++ b/xen/include/asm-x86/grant_table.h
@@ -14,6 +14,9 @@
 
 #define INITIAL_NR_GRANT_FRAMES 4
 
+struct grant_table_arch {
+};
+
 /*
  * Caller must own caller's BIGLOCK, is responsible for flushing the TLB, and
  * must hold a reference to the page.
@@ -36,6 +39,10 @@ static inline int replace_grant_host_mapping(uint64_t addr, unsigned long frame,
     return replace_grant_pv_mapping(addr, frame, new_addr, flags);
 }
 
+#define gnttab_init_arch(gt) 0
+#define gnttab_destroy_arch(gt) do {} while ( 0 )
+#define gnttab_set_frame_gfn(gt, idx, gfn) do {} while ( 0 )
+
 #define gnttab_create_shared_page(d, t, i)                               \
     do {                                                                 \
         share_xen_page_with_guest(                                       \
@@ -75,11 +82,6 @@ static inline void gnttab_clear_flag(unsigned int nr, uint16_t *st)
     asm volatile ("lock btrw %w1,%0" : "=m" (*st) : "Ir" (nr), "m" (*st));
 }
 
-static inline void gnttab_set_frame_gfn(struct domain *d, unsigned long idx,
-                                        gfn_t gfn)
-{
-}
-
 /* Foreign mappings of HHVM-guest pages do not modify the type count. */
 #define gnttab_host_mapping_get_page_type(ro, ld, rd)   \
     (!(ro) && (((ld) == (rd)) || !paging_mode_external(rd)))
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index df11b31264..d2bd2416c4 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -29,6 +29,8 @@
 #include <asm/page.h>
 #include <asm/grant_table.h>
 
+struct grant_table;
+
 /* The maximum size of a grant table. */
 extern unsigned int max_grant_frames;
 
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 09/11] xen: make grant resource limits per domain
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
                   ` (7 preceding siblings ...)
  2017-09-25 10:00 ` [PATCH v10 08/11] xen/arm: move arch specific grant table bits into grant_table.c Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 11:49   ` Jan Beulich
  2017-09-28  0:26   ` Julien Grall
  2017-09-25 10:00 ` [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info Juergen Gross
  2017-09-25 10:00 ` [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h Juergen Gross
  10 siblings, 2 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Instead of using the same global resource limits of grant tables (max.
number of grant frames, max. number of maptrack frames) for all domains
make these limits per domain. Set those per-domain limits in
grant_table_set_limits(). The global settings are serving as an upper
boundary now which must not be exceeded by a per-domain value. The
default of max_grant_frames is set to the maximum default xl will use.

While updating the semantics of the boot parameters remove the
documentation of the no longer existing gnttab_max_nr_frames and
correct the default gnttab_max_maptrack_frames uses.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V10:
- lower INITIAL_NR_GRANT_FRAMES value to 1
- removed no longer needed variables (Jan Beulich)
- stream lined messages (Jan Beulich)
- corrected setting of gnttab_size on ARM

V9:
- add caps for per-domain limits (Jan Beulich)
- some error messages enhanced (Jan Beulich)
- adjusted some types (Jan Beulich)
- merge parts of (former) patch 14 into this one
- make parameters changeable at runtime
- limit size of dom0's grant table on ARM
- set default max_grant_frames to 64

V6:
- several changes due to new patch order

V3:
- correct error message (Paul Durrant)
---
 docs/misc/xen-command-line.markdown |  25 +++---
 xen/arch/arm/domain_build.c         |   6 +-
 xen/common/compat/grant_table.c     |  31 ++-----
 xen/common/grant_table.c            | 156 +++++++++++++++++++++---------------
 xen/include/asm-arm/grant_table.h   |  13 ++-
 xen/include/asm-x86/grant_table.h   |   7 +-
 xen/include/xen/grant_table.h       |   5 +-
 7 files changed, 131 insertions(+), 112 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 9797c8db2d..9b6cd8e9d0 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -875,27 +875,28 @@ Specify which console gdbstub should use. See **console**.
 ### gnttab\_max\_frames
 > `= <integer>`
 
-> Default: `32`
+> Default: `64`
+
+> Can be modified at runtime
 
 Specify the maximum number of frames which any domain may use as part
-of its grant table.
+of its grant table. This value is an upper boundary of the per-domain
+value settable via Xen tools.
+
+Dom0 is using this value for sizing its grant table.
 
 ### gnttab\_max\_maptrack\_frames
 > `= <integer>`
 
-> Default: `8 * gnttab_max_frames`
-
-Specify the maximum number of frames to use as part of a domains
-maptrack array.
+> Default: `1024`
 
-### gnttab\_max\_nr\_frames
-> `= <integer>`
+> Can be modified at runtime
 
-*Deprecated*
-Use **gnttab\_max\_frames** and **gnttab\_max\_maptrack\_frames** instead.
+Specify the maximum number of frames to use as part of a domains
+maptrack array. This value is an upper boundary of the per-domain
+value settable via Xen tools.
 
-Specify the maximum number of frames per grant table operation and the
-maximum number of maptrack frames domain.
+Dom0 is using this value for sizing its maptrack table.
 
 ### guest\_loglvl
 > `= <level>[/<rate-limited level>]` where level is `none | error | warning | info | debug | all`
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c34238ec1b..3723dc3f78 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2095,11 +2095,7 @@ static void __init find_gnttab_region(struct domain *d,
      * enough space for a large grant table
      */
     kinfo->gnttab_start = __pa(_stext);
-    kinfo->gnttab_size = (_etext - _stext) & PAGE_MASK;
-
-    /* Make sure the grant table will fit in the region */
-    if ( (kinfo->gnttab_size >> PAGE_SHIFT) < max_grant_frames )
-        panic("Cannot find a space for the grant table region\n");
+    kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
 
 #ifdef CONFIG_ARM_32
     /*
diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
index cce3ff0b9a..ff1d678f01 100644
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -157,21 +157,14 @@ int compat_grant_table_op(unsigned int cmd,
                 unsigned int max_frame_list_size_in_page =
                     (COMPAT_ARG_XLAT_SIZE - sizeof(*nat.setup)) /
                     sizeof(*nat.setup->frame_list.p);
-                if ( max_frame_list_size_in_page < max_grant_frames )
-                {
-                    gdprintk(XENLOG_WARNING,
-                             "max_grant_frames is too large (%u,%u)\n",
-                             max_grant_frames, max_frame_list_size_in_page);
-                    rc = -EINVAL;
-                }
-                else
-                {
+
 #define XLAT_gnttab_setup_table_HNDL_frame_list(_d_, _s_) \
-                    set_xen_guest_handle((_d_)->frame_list, (unsigned long *)(nat.setup + 1))
-                    XLAT_gnttab_setup_table(nat.setup, &cmp.setup);
+                set_xen_guest_handle((_d_)->frame_list, (unsigned long *)(nat.setup + 1))
+                XLAT_gnttab_setup_table(nat.setup, &cmp.setup);
 #undef XLAT_gnttab_setup_table_HNDL_frame_list
-                    rc = gnttab_setup_table(guest_handle_cast(nat.uop, gnttab_setup_table_t), 1);
-                }
+                rc = gnttab_setup_table(guest_handle_cast(nat.uop,
+                                                          gnttab_setup_table_t),
+                                        1, max_frame_list_size_in_page);
             }
             ASSERT(rc <= 0);
             if ( rc == 0 )
@@ -294,16 +287,6 @@ int compat_grant_table_op(unsigned int cmd,
                 rc = -EFAULT;
                 break;
             }
-            if ( max_frame_list_size_in_pages <
-                 grant_to_status_frames(max_grant_frames) )
-            {
-                gdprintk(XENLOG_WARNING,
-                         "grant_to_status_frames(max_grant_frames) is too large (%u,%u)\n",
-                         grant_to_status_frames(max_grant_frames),
-                         max_frame_list_size_in_pages);
-                rc = -EINVAL;
-                break;
-            }
 
 #define XLAT_gnttab_get_status_frames_HNDL_frame_list(_d_, _s_) \
             set_xen_guest_handle((_d_)->frame_list, (uint64_t *)(nat.get_status + 1))
@@ -312,7 +295,7 @@ int compat_grant_table_op(unsigned int cmd,
 
             rc = gnttab_get_status_frames(
                 guest_handle_cast(nat.uop, gnttab_get_status_frames_t),
-                count);
+                count, max_frame_list_size_in_pages);
             if ( rc >= 0 )
             {
 #define XLAT_gnttab_get_status_frames_HNDL_frame_list(_d_, _s_) \
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 71706f5cba..7c328b0a62 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -54,6 +54,9 @@ struct grant_table {
      * what version to use yet.
      */
     unsigned int          gt_version;
+    /* Resource limits of the domain. */
+    unsigned int          max_grant_frames;
+    unsigned int          max_maptrack_frames;
     /* Table size. Number of frames shared with guest */
     unsigned int          nr_grant_frames;
     /* Number of grant status frames shared with guest (for version 2) */
@@ -78,23 +81,18 @@ struct grant_table {
 
 #ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
 /* Default maximum size of a grant table. [POLICY] */
-#define DEFAULT_MAX_NR_GRANT_FRAMES   32
+#define DEFAULT_MAX_NR_GRANT_FRAMES   64
 #endif
 
-unsigned int __read_mostly max_grant_frames;
-integer_param("gnttab_max_frames", max_grant_frames);
+static unsigned int __read_mostly max_grant_frames =
+                                               DEFAULT_MAX_NR_GRANT_FRAMES;
+integer_runtime_param("gnttab_max_frames", max_grant_frames);
 
-/* The maximum number of grant mappings is defined as a multiplier of the
- * maximum number of grant table entries. This defines the multiplier used.
- * Pretty arbitrary. [POLICY]
- * As gnttab_max_nr_frames has been deprecated, this multiplier is deprecated too.
- * New options allow to set max_maptrack_frames and
- * map_grant_table_frames independently.
- */
 #define DEFAULT_MAX_MAPTRACK_FRAMES 1024
 
-static unsigned int __read_mostly max_maptrack_frames;
-integer_param("gnttab_max_maptrack_frames", max_maptrack_frames);
+static unsigned int __read_mostly max_maptrack_frames =
+                                               DEFAULT_MAX_MAPTRACK_FRAMES;
+integer_runtime_param("gnttab_max_maptrack_frames", max_maptrack_frames);
 
 /*
  * Note that the three values below are effectively part of the ABI, even if
@@ -290,8 +288,8 @@ num_act_frames_from_sha_frames(const unsigned int num)
     return DIV_ROUND_UP(num * sha_per_page, ACGNT_PER_PAGE);
 }
 
-#define max_nr_active_grant_frames \
-    num_act_frames_from_sha_frames(max_grant_frames)
+#define max_nr_active_grant_frames(gt) \
+    num_act_frames_from_sha_frames((gt)->max_grant_frames)
 
 static inline unsigned int
 nr_active_grant_frames(struct grant_table *gt)
@@ -530,7 +528,7 @@ get_maptrack_handle(
      * out of memory, try stealing an entry from another VCPU (in case the
      * guest isn't mapping across its VCPUs evenly).
      */
-    if ( nr_maptrack_frames(lgt) < max_maptrack_frames )
+    if ( nr_maptrack_frames(lgt) < lgt->max_maptrack_frames )
         new_mt = alloc_xenheap_page();
 
     if ( !new_mt )
@@ -1673,7 +1671,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
 
     if ( req_nr_frames < INITIAL_NR_GRANT_FRAMES )
         req_nr_frames = INITIAL_NR_GRANT_FRAMES;
-    ASSERT(req_nr_frames <= max_grant_frames);
+    ASSERT(req_nr_frames <= gt->max_grant_frames);
 
     gdprintk(XENLOG_INFO,
             "Expanding dom (%d) grant table from (%d) to (%d) frames.\n",
@@ -1730,7 +1728,8 @@ active_alloc_failed:
 }
 
 static int
-grant_table_init(struct domain *d, struct grant_table *gt)
+grant_table_init(struct domain *d, struct grant_table *gt,
+                 unsigned int grant_frames, unsigned int maptrack_frames)
 {
     int ret;
 
@@ -1742,25 +1741,31 @@ grant_table_init(struct domain *d, struct grant_table *gt)
         goto unlock;
     }
 
+    gt->max_grant_frames = grant_frames;
+    gt->max_maptrack_frames = maptrack_frames;
+
     /* Active grant table. */
     gt->active = xzalloc_array(struct active_grant_entry *,
-                               max_nr_active_grant_frames);
+                               max_nr_active_grant_frames(gt));
     if ( gt->active == NULL )
         goto no_mem;
 
     /* Tracking of mapped foreign frames table */
-    gt->maptrack = vzalloc(max_maptrack_frames * sizeof(*gt->maptrack));
-    if ( gt->maptrack == NULL )
-        goto no_mem;
+    if ( gt->max_maptrack_frames )
+    {
+        gt->maptrack = vzalloc(gt->max_maptrack_frames * sizeof(*gt->maptrack));
+        if ( gt->maptrack == NULL )
+            goto no_mem;
+    }
 
     /* Shared grant table. */
-    gt->shared_raw = xzalloc_array(void *, max_grant_frames);
+    gt->shared_raw = xzalloc_array(void *, gt->max_grant_frames);
     if ( gt->shared_raw == NULL )
         goto no_mem;
 
     /* Status pages for grant table - for version 2 */
     gt->status = xzalloc_array(grant_status_t *,
-                               grant_to_status_frames(max_grant_frames));
+                               grant_to_status_frames(gt->max_grant_frames));
     if ( gt->status == NULL )
         goto no_mem;
 
@@ -1793,7 +1798,8 @@ grant_table_init(struct domain *d, struct grant_table *gt)
 
 static long
 gnttab_setup_table(
-    XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count,
+    unsigned int limit_max)
 {
     struct vcpu *curr = current;
     struct gnttab_setup_table op;
@@ -1807,15 +1813,6 @@ gnttab_setup_table(
     if ( unlikely(copy_from_guest(&op, uop, 1)) )
         return -EFAULT;
 
-    if ( unlikely(op.nr_frames > max_grant_frames) )
-    {
-        gdprintk(XENLOG_INFO, "Xen only supports up to %d grant-table frames"
-                " per domain.\n",
-                max_grant_frames);
-        op.status = GNTST_general_error;
-        goto out;
-    }
-
     if ( !guest_handle_okay(op.frame_list, op.nr_frames) )
         return -EFAULT;
 
@@ -1835,6 +1832,21 @@ gnttab_setup_table(
     gt = d->grant_table;
     grant_write_lock(gt);
 
+    if ( unlikely(op.nr_frames > gt->max_grant_frames) )
+    {
+        gdprintk(XENLOG_INFO, "d%d is limited to %u grant-table frames.\n",
+                d->domain_id, gt->max_grant_frames);
+        op.status = GNTST_general_error;
+        goto unlock;
+    }
+    if ( unlikely(limit_max < op.nr_frames) )
+    {
+        gdprintk(XENLOG_WARNING, "nr_frames for d%d is too large (%u,%u)\n",
+                 d->domain_id, op.nr_frames, limit_max);
+        op.status = GNTST_general_error;
+        goto unlock;
+    }
+
     if ( gt->gt_version == 0 )
         gt->gt_version = 1;
 
@@ -1844,8 +1856,9 @@ gnttab_setup_table(
          !gnttab_grow_table(d, op.nr_frames) )
     {
         gdprintk(XENLOG_INFO,
-                 "Expand grant table to %u failed. Current: %u Max: %u\n",
-                 op.nr_frames, nr_grant_frames(gt), max_grant_frames);
+                 "Expand grant table of d%d to %u failed. Current: %u Max: %u\n",
+                 d->domain_id, op.nr_frames, nr_grant_frames(gt),
+                 gt->max_grant_frames);
         op.status = GNTST_general_error;
         goto unlock;
     }
@@ -1880,6 +1893,7 @@ gnttab_query_size(
 {
     struct gnttab_query_size op;
     struct domain *d;
+    struct grant_table *gt;
 
     if ( count != 1 )
         return -EINVAL;
@@ -1900,13 +1914,15 @@ gnttab_query_size(
         goto out;
     }
 
-    grant_read_lock(d->grant_table);
+    gt = d->grant_table;
+
+    grant_read_lock(gt);
 
-    op.nr_frames     = nr_grant_frames(d->grant_table);
-    op.max_nr_frames = max_grant_frames;
+    op.nr_frames     = nr_grant_frames(gt);
+    op.max_nr_frames = gt->max_grant_frames;
     op.status        = GNTST_okay;
 
-    grant_read_unlock(d->grant_table);
+    grant_read_unlock(gt);
 
  out:
     if ( d )
@@ -2981,7 +2997,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
 
 static long
 gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
-                         int count)
+                         unsigned int count, unsigned int limit_max)
 {
     gnttab_get_status_frames_t op;
     struct domain *d;
@@ -3021,9 +3037,19 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
 
     if ( unlikely(op.nr_frames > nr_status_frames(gt)) )
     {
-        gdprintk(XENLOG_INFO, "Guest requested addresses for %d grant status "
-                 "frames, but only %d are available.\n",
-                 op.nr_frames, nr_status_frames(gt));
+        gdprintk(XENLOG_INFO, "Requested addresses of d%d for %u grant "
+                 "status frames, but has only %u.\n",
+                 d->domain_id, op.nr_frames, nr_status_frames(gt));
+        op.status = GNTST_general_error;
+        goto unlock;
+    }
+
+    if ( unlikely(limit_max < grant_to_status_frames(op.nr_frames)) )
+    {
+        gdprintk(XENLOG_WARNING,
+                 "grant_to_status_frames(%u) for d%d is too large (%u,%u)\n",
+                 op.nr_frames, d->domain_id,
+                 grant_to_status_frames(op.nr_frames), limit_max);
         op.status = GNTST_general_error;
         goto unlock;
     }
@@ -3336,7 +3362,7 @@ do_grant_table_op(
 
     case GNTTABOP_setup_table:
         rc = gnttab_setup_table(
-            guest_handle_cast(uop, gnttab_setup_table_t), count);
+            guest_handle_cast(uop, gnttab_setup_table_t), count, UINT_MAX);
         ASSERT(rc <= 0);
         break;
 
@@ -3385,7 +3411,8 @@ do_grant_table_op(
 
     case GNTTABOP_get_status_frames:
         rc = gnttab_get_status_frames(
-            guest_handle_cast(uop, gnttab_get_status_frames_t), count);
+            guest_handle_cast(uop, gnttab_get_status_frames_t), count,
+                              UINT_MAX);
         break;
 
     case GNTTABOP_get_version:
@@ -3465,7 +3492,7 @@ grant_table_create(
 
     if ( d->domain_id == 0 )
     {
-        ret = grant_table_init(d, t);
+        ret = grant_table_init(d, t, gnttab_dom0_frames(), max_maptrack_frames);
     }
 
     return ret;
@@ -3666,11 +3693,15 @@ int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
 {
     struct grant_table *gt = d->grant_table;
 
+    if ( grant_frames < INITIAL_NR_GRANT_FRAMES ||
+         grant_frames > max_grant_frames ||
+         maptrack_frames > max_maptrack_frames )
+        return -EINVAL;
     if ( !gt )
         return -ENOENT;
 
     /* Set limits. */
-    return grant_table_init(d, gt);
+    return grant_table_init(d, gt, grant_frames, maptrack_frames);
 }
 
 #ifdef CONFIG_HAS_MEM_SHARING
@@ -3742,7 +3773,7 @@ int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
     }
     else
     {
-        if ( (idx >= nr_grant_frames(gt)) && (idx < max_grant_frames) )
+        if ( (idx >= nr_grant_frames(gt)) && (idx < gt->max_grant_frames) )
             gnttab_grow_table(d, idx + 1);
 
         if ( idx < nr_grant_frames(gt) )
@@ -3770,6 +3801,12 @@ static void gnttab_usage_print(struct domain *rd)
 
     grant_read_lock(gt);
 
+    printk("grant-table for remote d%d (v%u)\n"
+           "  %u frames (%u max), %u maptrack frames (%u max)\n",
+           rd->domain_id, gt->gt_version,
+           nr_grant_frames(gt), gt->max_grant_frames,
+           nr_maptrack_frames(gt), gt->max_maptrack_frames);
+
     for ( ref = 0; ref != nr_grant_entries(gt); ref++ )
     {
         struct active_grant_entry *act;
@@ -3797,12 +3834,7 @@ static void gnttab_usage_print(struct domain *rd)
             status = status_entry(gt, ref);
         }
 
-        if ( first )
-        {
-            printk("grant-table for remote domain:%5d (v%d)\n",
-                   rd->domain_id, gt->gt_version);
-            first = 0;
-        }
+        first = 0;
 
         /*      [0xXXX]  ddddd 0xXXXXXX 0xXXXXXXXX      ddddd 0xXXXXXX 0xXX */
         printk("[0x%03x]  %5d 0x%06lx 0x%08x      %5d 0x%06"PRIx64" 0x%02x\n",
@@ -3814,8 +3846,7 @@ static void gnttab_usage_print(struct domain *rd)
     grant_read_unlock(gt);
 
     if ( first )
-        printk("grant-table for remote domain:%5d ... "
-               "no active grant table entries\n", rd->domain_id);
+        printk("no active grant table entries\n");
 }
 
 static void gnttab_usage_print_all(unsigned char key)
@@ -3829,20 +3860,17 @@ static void gnttab_usage_print_all(unsigned char key)
 
 static int __init gnttab_usage_init(void)
 {
-    BUILD_BUG_ON(DEFAULT_MAX_MAPTRACK_FRAMES < DEFAULT_MAX_NR_GRANT_FRAMES);
-
-    if ( !max_grant_frames )
-        max_grant_frames = DEFAULT_MAX_NR_GRANT_FRAMES;
-
-    if ( !max_maptrack_frames )
-        max_maptrack_frames = DEFAULT_MAX_MAPTRACK_FRAMES;
-
     register_keyhandler('g', gnttab_usage_print_all,
                         "print grant table usage", 1);
     return 0;
 }
 __initcall(gnttab_usage_init);
 
+unsigned int __init gnttab_dom0_frames(void)
+{
+    return min(max_grant_frames, gnttab_dom0_max());
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
index 30db2d1616..bcdeada9ca 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -2,9 +2,11 @@
 #define __ASM_GRANT_TABLE_H__
 
 #include <xen/grant_table.h>
+#include <xen/kernel.h>
+#include <xen/pfn.h>
 #include <xen/sched.h>
 
-#define INITIAL_NR_GRANT_FRAMES 4
+#define INITIAL_NR_GRANT_FRAMES 1U
 
 struct grant_table_arch {
     gfn_t *gfn;
@@ -26,9 +28,14 @@ static inline int replace_grant_supported(void)
     return 1;
 }
 
+static inline unsigned int gnttab_dom0_max(void)
+{
+    return PFN_DOWN(_etext - _stext);
+}
+
 #define gnttab_init_arch(gt)                                             \
 ({                                                                       \
-    (gt)->arch.gfn = xzalloc_array(gfn_t, max_grant_frames);             \
+    (gt)->arch.gfn = xzalloc_array(gfn_t, (gt)->max_grant_frames);       \
     ( (gt)->arch.gfn ? 0 : -ENOMEM );                                    \
 })
 
@@ -52,7 +59,7 @@ static inline int replace_grant_supported(void)
 
 #define gnttab_shared_gmfn(d, t, i)                                      \
     ( ((i >= nr_grant_frames(t)) &&                                      \
-       (i < max_grant_frames)) ? 0 : gfn_x(t->arch.gfn[i]))
+       (i < (t)->max_grant_frames))? 0 : gfn_x((t)->arch.gfn[i]))
 
 #define gnttab_need_iommu_mapping(d)                    \
     (is_domain_direct_mapped(d) && need_iommu(d))
diff --git a/xen/include/asm-x86/grant_table.h b/xen/include/asm-x86/grant_table.h
index 1b93c5720d..d9157e4417 100644
--- a/xen/include/asm-x86/grant_table.h
+++ b/xen/include/asm-x86/grant_table.h
@@ -12,7 +12,7 @@
 #include <asm/hvm/grant_table.h>
 #include <asm/pv/grant_table.h>
 
-#define INITIAL_NR_GRANT_FRAMES 4
+#define INITIAL_NR_GRANT_FRAMES 1U
 
 struct grant_table_arch {
 };
@@ -39,6 +39,11 @@ static inline int replace_grant_host_mapping(uint64_t addr, unsigned long frame,
     return replace_grant_pv_mapping(addr, frame, new_addr, flags);
 }
 
+static inline unsigned int gnttab_dom0_max(void)
+{
+    return UINT_MAX;
+}
+
 #define gnttab_init_arch(gt) 0
 #define gnttab_destroy_arch(gt) do {} while ( 0 )
 #define gnttab_set_frame_gfn(gt, idx, gfn) do {} while ( 0 )
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index d2bd2416c4..b3a95fda58 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -31,9 +31,6 @@
 
 struct grant_table;
 
-/* The maximum size of a grant table. */
-extern unsigned int max_grant_frames;
-
 /* Create/destroy per-domain grant table context. */
 int grant_table_create(
     struct domain *d);
@@ -59,4 +56,6 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
 int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
                      mfn_t *mfn);
 
+unsigned int gnttab_dom0_frames(void);
+
 #endif /* __XEN_GRANT_TABLE_H__ */
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
                   ` (8 preceding siblings ...)
  2017-09-25 10:00 ` [PATCH v10 09/11] xen: make grant resource limits per domain Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 11:55   ` Andrew Cooper
                     ` (3 more replies)
  2017-09-25 10:00 ` [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h Juergen Gross
  10 siblings, 4 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

On very large hosts a pv-guest needs to know whether it will have to
handle frame numbers larger than 32 bits in order to select the
appropriate grant interface version.

Add a new Xen specific CPUID node to contain the maximum machine address
width similar to the x86 CPUID node 0x80000008 containing the maximum
physical address width. The maximum frame width needs to take memory
hotplug into account.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
V10:
- correct comment in cpuid.h (Jan Beulich)

V9:
- make leaf pv-only (Jan Beulich)
- use hex value for mask (Jan Beulich)
- guest address width -> machine address width (Jan Beulich)
---
 xen/arch/x86/traps.c                |  7 +++++++
 xen/include/public/arch-x86/cpuid.h | 11 ++++++++++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index d8feef2942..2b464d02ef 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
         res->b = v->vcpu_id;
         break;
 
+    case 5: /* PV-specific parameters */
+        if ( is_hvm_domain(d) || subleaf != 0 )
+            break;
+
+        res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
+        break;
+
     default:
         ASSERT_UNREACHABLE();
     }
diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
index d709340f18..2bc11bf6ef 100644
--- a/xen/include/public/arch-x86/cpuid.h
+++ b/xen/include/public/arch-x86/cpuid.h
@@ -85,6 +85,15 @@
 #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
 #define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu id is present in EBX */
 
-#define XEN_CPUID_MAX_NUM_LEAVES 4
+/*
+ * Leaf 6 (0x40000x05)
+ * PV-specific parameters
+ * Sub-leaf 0: EAX: bits 0-7: max machine address width
+ */
+
+/* Max. address width in bits taking memory hotplug into account. */
+#define XEN_CPUID_MACHINE_ADDRESS_WIDTH_MASK (0xffu << 0)
+
+#define XEN_CPUID_MAX_NUM_LEAVES 5
 
 #endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h
  2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
                   ` (9 preceding siblings ...)
  2017-09-25 10:00 ` [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info Juergen Gross
@ 2017-09-25 10:00 ` Juergen Gross
  2017-09-25 12:01   ` Jan Beulich
  10 siblings, 1 reply; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 10:00 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, jbeulich,
	dgdegra

Leaf 4 of the Xen-specific CPUID leaves isn't mentioned at all in
include/public/arch-x86/cpuid.h, the comments for leaf 5 don't tell
anything about the sub-leaf semantics.

Add comments to clarify the interface.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/include/public/arch-x86/cpuid.h | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
index 2bc11bf6ef..7bc1dd921c 100644
--- a/xen/include/public/arch-x86/cpuid.h
+++ b/xen/include/public/arch-x86/cpuid.h
@@ -74,10 +74,26 @@
 #define XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD  (1u<<0)
 
 /*
+ * Leaf 4 (0x40000x03)
+ * Sub-leaf 0: EAX: bit 0: emulated tsc
+ *                  bit 1: host tsc is known to be reliable
+ *                  bit 2: RDTSCP instruction available
+ *             EBX: tsc_mode: 0=default (emulate if necessary), 1=emulate,
+ *                            2=no emulation, 3=no emulation + TSC_AUX support
+ *             ECX: guest tsc frequency in kHz
+ *             EDX: guest tsc incarnation (migration count)
+ * Sub-leaf 1: EAX: tsc offset low part
+ *             EBX: tsc offset high part
+ *             ECX: multiplicator for tsc->ns conversion
+ *             EDX: shift amount for tsc->ns conversion
+ * Sub-leaf 2: EAX: host tsc frequency in kHz
+ */
+
+/*
  * Leaf 5 (0x40000x04)
  * HVM-specific features
- * EAX: Features
- * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag)
+ * Sub-leaf 0: EAX: Features
+ * Sub-leaf 0: EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag)
  */
 #define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */
 #define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized x2APIC accesses */
-- 
2.12.3


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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 07/11] xen: delay allocation of grant table sub structures
  2017-09-25 10:00 ` [PATCH v10 07/11] xen: delay allocation of grant table sub structures Juergen Gross
@ 2017-09-25 10:16   ` Jan Beulich
  2017-09-28 18:56   ` Andrew Cooper
  1 sibling, 0 replies; 35+ messages in thread
From: Jan Beulich @ 2017-09-25 10:16 UTC (permalink / raw)
  To: Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, xen-devel, dgdegra

>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
> Delay the allocation of the grant table sub structures in order to
> allow modifying parameters needed for sizing of these structures at a
> per domain basis. Allocate the structures and the table frames only
> from grant_table_init().
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 01/11] xen: add function for obtaining highest possible memory address
  2017-09-25 10:00 ` [PATCH v10 01/11] xen: add function for obtaining highest possible memory address Juergen Gross
@ 2017-09-25 10:19   ` Jan Beulich
  2017-09-28  0:29   ` Julien Grall
  1 sibling, 0 replies; 35+ messages in thread
From: Jan Beulich @ 2017-09-25 10:19 UTC (permalink / raw)
  To: Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, xen-devel, dgdegra

>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
> @@ -96,14 +96,15 @@ struct xen_sysctl_physinfo {
>      uint32_t nr_nodes;    /* # nodes currently online */
>      uint32_t max_node_id; /* Largest possible node ID on this host */
>      uint32_t cpu_khz;
> +    uint32_t capabilities; /* XEN_SYSCTL_PHYSCAP_??? */
> +
>      uint64_aligned_t total_pages;
>      uint64_aligned_t free_pages;
>      uint64_aligned_t scrub_pages;
>      uint64_aligned_t outstanding_pages;
>      uint32_t hw_cap[8];
>  
> -    /* XEN_SYSCTL_PHYSCAP_??? */
> -    uint32_t capabilities;
> +    uint64_aligned_t max_mfn; /* Largest possible MFN on this host */
>  };

Should I end up committing this, I'll likely take the liberty any also
move the addition up next to the other uint64_aligned_t fields.
That'll allow the initial portion of the structure to remain stable
whenever hw_cap[] gets dropped from it.

Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 09/11] xen: make grant resource limits per domain
  2017-09-25 10:00 ` [PATCH v10 09/11] xen: make grant resource limits per domain Juergen Gross
@ 2017-09-25 11:49   ` Jan Beulich
  2017-09-28  0:26   ` Julien Grall
  1 sibling, 0 replies; 35+ messages in thread
From: Jan Beulich @ 2017-09-25 11:49 UTC (permalink / raw)
  To: Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, xen-devel, dgdegra

>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
> Instead of using the same global resource limits of grant tables (max.
> number of grant frames, max. number of maptrack frames) for all domains
> make these limits per domain. Set those per-domain limits in
> grant_table_set_limits(). The global settings are serving as an upper
> boundary now which must not be exceeded by a per-domain value. The
> default of max_grant_frames is set to the maximum default xl will use.
> 
> While updating the semantics of the boot parameters remove the
> documentation of the no longer existing gnttab_max_nr_frames and
> correct the default gnttab_max_maptrack_frames uses.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Except for the ARM parts
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-25 10:00 ` [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info Juergen Gross
@ 2017-09-25 11:55   ` Andrew Cooper
  2017-09-25 12:00     ` Juergen Gross
  2017-09-25 11:59   ` Jan Beulich
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 35+ messages in thread
From: Andrew Cooper @ 2017-09-25 11:55 UTC (permalink / raw)
  To: Juergen Gross, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, tim, ian.jackson,
	julien.grall, jbeulich, dgdegra

On 25/09/17 11:00, Juergen Gross wrote:
> On very large hosts a pv-guest needs to know whether it will have to
> handle frame numbers larger than 32 bits in order to select the
> appropriate grant interface version.
>
> Add a new Xen specific CPUID node to contain the maximum machine address
> width similar to the x86 CPUID node 0x80000008 containing the maximum
> physical address width. The maximum frame width needs to take memory
> hotplug into account.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> V10:
> - correct comment in cpuid.h (Jan Beulich)
>
> V9:
> - make leaf pv-only (Jan Beulich)
> - use hex value for mask (Jan Beulich)
> - guest address width -> machine address width (Jan Beulich)
> ---
>  xen/arch/x86/traps.c                |  7 +++++++
>  xen/include/public/arch-x86/cpuid.h | 11 ++++++++++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index d8feef2942..2b464d02ef 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
>          res->b = v->vcpu_id;
>          break;
>  
> +    case 5: /* PV-specific parameters */
> +        if ( is_hvm_domain(d) || subleaf != 0 )
> +            break;

Leaves 3 and 4 are currently broken in terms of their subleaf handling,
and can't easily be fixed (as the ABI is set in stone).  However, please
lets not propagate the brokenness into new leaves.

5/0 should report max_subleaf in res->a, in the same way as other
subleafs get handled.

~Andrew

> +
> +        res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
> +        break;
> +
>      default:
>          ASSERT_UNREACHABLE();
>      }
> diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
> index d709340f18..2bc11bf6ef 100644
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -85,6 +85,15 @@
>  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
>  #define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu id is present in EBX */
>  
> -#define XEN_CPUID_MAX_NUM_LEAVES 4
> +/*
> + * Leaf 6 (0x40000x05)
> + * PV-specific parameters
> + * Sub-leaf 0: EAX: bits 0-7: max machine address width
> + */
> +
> +/* Max. address width in bits taking memory hotplug into account. */
> +#define XEN_CPUID_MACHINE_ADDRESS_WIDTH_MASK (0xffu << 0)
> +
> +#define XEN_CPUID_MAX_NUM_LEAVES 5
>  
>  #endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-25 10:00 ` [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info Juergen Gross
  2017-09-25 11:55   ` Andrew Cooper
@ 2017-09-25 11:59   ` Jan Beulich
  2017-09-28  8:59   ` Jan Beulich
       [not found]   ` <59CCD61D0200007800180567@suse.com>
  3 siblings, 0 replies; 35+ messages in thread
From: Jan Beulich @ 2017-09-25 11:59 UTC (permalink / raw)
  To: Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, xen-devel, dgdegra

>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
> On very large hosts a pv-guest needs to know whether it will have to
> handle frame numbers larger than 32 bits in order to select the
> appropriate grant interface version.
> 
> Add a new Xen specific CPUID node to contain the maximum machine address
> width similar to the x86 CPUID node 0x80000008 containing the maximum
> physical address width. The maximum frame width needs to take memory
> hotplug into account.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

But still going to wait for a little while for possible other feedback,
in particular by Andrew.

Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-25 11:55   ` Andrew Cooper
@ 2017-09-25 12:00     ` Juergen Gross
  2017-09-25 12:02       ` Andrew Cooper
  2017-09-25 12:03       ` Jan Beulich
  0 siblings, 2 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-25 12:00 UTC (permalink / raw)
  To: Andrew Cooper, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, tim, ian.jackson,
	julien.grall, jbeulich, dgdegra

On 25/09/17 13:55, Andrew Cooper wrote:
> On 25/09/17 11:00, Juergen Gross wrote:
>> On very large hosts a pv-guest needs to know whether it will have to
>> handle frame numbers larger than 32 bits in order to select the
>> appropriate grant interface version.
>>
>> Add a new Xen specific CPUID node to contain the maximum machine address
>> width similar to the x86 CPUID node 0x80000008 containing the maximum
>> physical address width. The maximum frame width needs to take memory
>> hotplug into account.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> V10:
>> - correct comment in cpuid.h (Jan Beulich)
>>
>> V9:
>> - make leaf pv-only (Jan Beulich)
>> - use hex value for mask (Jan Beulich)
>> - guest address width -> machine address width (Jan Beulich)
>> ---
>>  xen/arch/x86/traps.c                |  7 +++++++
>>  xen/include/public/arch-x86/cpuid.h | 11 ++++++++++-
>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>> index d8feef2942..2b464d02ef 100644
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
>>          res->b = v->vcpu_id;
>>          break;
>>  
>> +    case 5: /* PV-specific parameters */
>> +        if ( is_hvm_domain(d) || subleaf != 0 )
>> +            break;
> 
> Leaves 3 and 4 are currently broken in terms of their subleaf handling,
> and can't easily be fixed (as the ABI is set in stone).  However, please
> lets not propagate the brokenness into new leaves.
> 
> 5/0 should report max_subleaf in res->a, in the same way as other
> subleafs get handled.

Aah, okay. So it should be okay to move the data below to res->b of
sub-leaf 0 then, I guess?


Juergen

> 
> ~Andrew
> 
>> +
>> +        res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
>> +        break;
>> +
>>      default:
>>          ASSERT_UNREACHABLE();
>>      }
>> diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
>> index d709340f18..2bc11bf6ef 100644
>> --- a/xen/include/public/arch-x86/cpuid.h
>> +++ b/xen/include/public/arch-x86/cpuid.h
>> @@ -85,6 +85,15 @@
>>  #define XEN_HVM_CPUID_IOMMU_MAPPINGS   (1u << 2)
>>  #define XEN_HVM_CPUID_VCPU_ID_PRESENT  (1u << 3) /* vcpu id is present in EBX */
>>  
>> -#define XEN_CPUID_MAX_NUM_LEAVES 4
>> +/*
>> + * Leaf 6 (0x40000x05)
>> + * PV-specific parameters
>> + * Sub-leaf 0: EAX: bits 0-7: max machine address width
>> + */
>> +
>> +/* Max. address width in bits taking memory hotplug into account. */
>> +#define XEN_CPUID_MACHINE_ADDRESS_WIDTH_MASK (0xffu << 0)
>> +
>> +#define XEN_CPUID_MAX_NUM_LEAVES 5
>>  
>>  #endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */
> 
> 


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h
  2017-09-25 10:00 ` [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h Juergen Gross
@ 2017-09-25 12:01   ` Jan Beulich
  2017-09-28 11:50     ` George Dunlap
  0 siblings, 1 reply; 35+ messages in thread
From: Jan Beulich @ 2017-09-25 12:01 UTC (permalink / raw)
  To: julien.grall, Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, xen-devel, dgdegra

>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
> Leaf 4 of the Xen-specific CPUID leaves isn't mentioned at all in
> include/public/arch-x86/cpuid.h, the comments for leaf 5 don't tell
> anything about the sub-leaf semantics.
> 
> Add comments to clarify the interface.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

Julien,

strictly speaking this was posted too late for 4.10, but it being
comment changes only I think it's fine to take nevertheless?

Thanks, Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-25 12:00     ` Juergen Gross
@ 2017-09-25 12:02       ` Andrew Cooper
  2017-09-25 12:03       ` Jan Beulich
  1 sibling, 0 replies; 35+ messages in thread
From: Andrew Cooper @ 2017-09-25 12:02 UTC (permalink / raw)
  To: Juergen Gross, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, tim, ian.jackson,
	julien.grall, jbeulich, dgdegra

On 25/09/17 13:00, Juergen Gross wrote:
> On 25/09/17 13:55, Andrew Cooper wrote:
>> On 25/09/17 11:00, Juergen Gross wrote:
>>> On very large hosts a pv-guest needs to know whether it will have to
>>> handle frame numbers larger than 32 bits in order to select the
>>> appropriate grant interface version.
>>>
>>> Add a new Xen specific CPUID node to contain the maximum machine address
>>> width similar to the x86 CPUID node 0x80000008 containing the maximum
>>> physical address width. The maximum frame width needs to take memory
>>> hotplug into account.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>> V10:
>>> - correct comment in cpuid.h (Jan Beulich)
>>>
>>> V9:
>>> - make leaf pv-only (Jan Beulich)
>>> - use hex value for mask (Jan Beulich)
>>> - guest address width -> machine address width (Jan Beulich)
>>> ---
>>>  xen/arch/x86/traps.c                |  7 +++++++
>>>  xen/include/public/arch-x86/cpuid.h | 11 ++++++++++-
>>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>>> index d8feef2942..2b464d02ef 100644
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
>>>          res->b = v->vcpu_id;
>>>          break;
>>>  
>>> +    case 5: /* PV-specific parameters */
>>> +        if ( is_hvm_domain(d) || subleaf != 0 )
>>> +            break;
>> Leaves 3 and 4 are currently broken in terms of their subleaf handling,
>> and can't easily be fixed (as the ABI is set in stone).  However, please
>> lets not propagate the brokenness into new leaves.
>>
>> 5/0 should report max_subleaf in res->a, in the same way as other
>> subleafs get handled.
> Aah, okay. So it should be okay to move the data below to res->b of
> sub-leaf 0 then, I guess?

Yeah - that would be fine.

~Andrew

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-25 12:00     ` Juergen Gross
  2017-09-25 12:02       ` Andrew Cooper
@ 2017-09-25 12:03       ` Jan Beulich
  1 sibling, 0 replies; 35+ messages in thread
From: Jan Beulich @ 2017-09-25 12:03 UTC (permalink / raw)
  To: Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, Andrew Cooper, ian.jackson,
	tim, julien.grall, xen-devel, dgdegra

>>> On 25.09.17 at 14:00, <jgross@suse.com> wrote:
> On 25/09/17 13:55, Andrew Cooper wrote:
>> On 25/09/17 11:00, Juergen Gross wrote:
>>> On very large hosts a pv-guest needs to know whether it will have to
>>> handle frame numbers larger than 32 bits in order to select the
>>> appropriate grant interface version.
>>>
>>> Add a new Xen specific CPUID node to contain the maximum machine address
>>> width similar to the x86 CPUID node 0x80000008 containing the maximum
>>> physical address width. The maximum frame width needs to take memory
>>> hotplug into account.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>> V10:
>>> - correct comment in cpuid.h (Jan Beulich)
>>>
>>> V9:
>>> - make leaf pv-only (Jan Beulich)
>>> - use hex value for mask (Jan Beulich)
>>> - guest address width -> machine address width (Jan Beulich)
>>> ---
>>>  xen/arch/x86/traps.c                |  7 +++++++
>>>  xen/include/public/arch-x86/cpuid.h | 11 ++++++++++-
>>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>>> index d8feef2942..2b464d02ef 100644
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
> uint32_t leaf,
>>>          res->b = v->vcpu_id;
>>>          break;
>>>  
>>> +    case 5: /* PV-specific parameters */
>>> +        if ( is_hvm_domain(d) || subleaf != 0 )
>>> +            break;
>> 
>> Leaves 3 and 4 are currently broken in terms of their subleaf handling,
>> and can't easily be fixed (as the ABI is set in stone).  However, please
>> lets not propagate the brokenness into new leaves.
>> 
>> 5/0 should report max_subleaf in res->a, in the same way as other
>> subleafs get handled.
> 
> Aah, okay. So it should be okay to move the data below to res->b of
> sub-leaf 0 then, I guess?

And you can keep my ack with that change. In fact I think the
adjustment could easily be done while committing.

Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 09/11] xen: make grant resource limits per domain
  2017-09-25 10:00 ` [PATCH v10 09/11] xen: make grant resource limits per domain Juergen Gross
  2017-09-25 11:49   ` Jan Beulich
@ 2017-09-28  0:26   ` Julien Grall
  2017-09-28  7:21     ` Juergen Gross
  1 sibling, 1 reply; 35+ messages in thread
From: Julien Grall @ 2017-09-28  0:26 UTC (permalink / raw)
  To: Juergen Gross, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, jbeulich, dgdegra

Hi Juergen,

On 09/25/2017 11:00 AM, Juergen Gross wrote:
> diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
> index 30db2d1616..bcdeada9ca 100644
> --- a/xen/include/asm-arm/grant_table.h
> +++ b/xen/include/asm-arm/grant_table.h
> @@ -2,9 +2,11 @@
>   #define __ASM_GRANT_TABLE_H__
>   
>   #include <xen/grant_table.h>
> +#include <xen/kernel.h>
> +#include <xen/pfn.h>
>   #include <xen/sched.h>
>   
> -#define INITIAL_NR_GRANT_FRAMES 4
> +#define INITIAL_NR_GRANT_FRAMES 1U
>   
>   struct grant_table_arch {
>       gfn_t *gfn;
> @@ -26,9 +28,14 @@ static inline int replace_grant_supported(void)
>       return 1;
>   }
>   
> +static inline unsigned int gnttab_dom0_max(void)
> +{
> +    return PFN_DOWN(_etext - _stext);
> +}

I think you need a comment on top of this function explaining why you 
return this value. Re-using part of the comment in find_gnttab_region 
would be fine to me.

Cheers,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 01/11] xen: add function for obtaining highest possible memory address
  2017-09-25 10:00 ` [PATCH v10 01/11] xen: add function for obtaining highest possible memory address Juergen Gross
  2017-09-25 10:19   ` Jan Beulich
@ 2017-09-28  0:29   ` Julien Grall
  1 sibling, 0 replies; 35+ messages in thread
From: Julien Grall @ 2017-09-28  0:29 UTC (permalink / raw)
  To: Juergen Gross, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, jbeulich, dgdegra

Hi Juergen,

On 09/25/2017 11:00 AM, Juergen Gross wrote:
> Add a function for obtaining the highest possible physical memory
> address of the system. This value is influenced by:
> 
> - hypervisor configuration (CONFIG_BIGMEM)
> - processor capability (max. addressable physical memory)
> - memory map at boot time
> - memory hotplug capability
> 
> Add this value to xen_sysctl_physinfo in order to enable dom0 to do a
> proper sizing of grant frame limits of guests.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

> ---
> V10:
> - avoid holes in xen_sysctl_physinfo, use uint64_aligned_t
>    (Jan Beulich)
> 
> V9:
> - merge patch with following one (Jan Beulich)
> - bump sysctl interface version (Julien Grall)
> - drop thin common shim of get_upper_mfn_bound() (Jan Beulich)
> - let get_upper_mfn_bound() return the highest MFN, not the one
>    following it (Jan Beulich)
> ---
>   xen/arch/arm/mm.c           |  6 ++++++
>   xen/arch/x86/mm.c           | 11 +++++++++++
>   xen/common/sysctl.c         |  1 +
>   xen/include/public/sysctl.h |  7 ++++---
>   xen/include/xen/mm.h        |  3 +++
>   5 files changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index f3834b3dab..9a37f29ce6 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1472,6 +1472,12 @@ void clear_and_clean_page(struct page_info *page)
>       unmap_domain_page(p);
>   }
>   
> +unsigned long get_upper_mfn_bound(void)
> +{
> +    /* No memory hotplug yet, so current memory limit is the final one. */
> +    return max_page - 1;
> +}
> +
>   /*
>    * Local variables:
>    * mode: C
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index afd5a101a4..d9df5ca69f 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5178,6 +5178,17 @@ void write_32bit_pse_identmap(uint32_t *l2)
>                    _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
>   }
>   
> +unsigned long get_upper_mfn_bound(void)
> +{
> +    unsigned long max_mfn;
> +
> +    max_mfn = mem_hotplug ? PFN_DOWN(mem_hotplug) : max_page;
> +#ifndef CONFIG_BIGMEM
> +    max_mfn = min(max_mfn, 1UL << 32);
> +#endif
> +    return min(max_mfn, 1UL << (paddr_bits - PAGE_SHIFT)) - 1;
> +}
> +
>   /*
>    * Local variables:
>    * mode: C
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index 3480f582fa..08198b7150 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -266,6 +266,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>           get_outstanding_claims(&pi->free_pages, &pi->outstanding_pages);
>           pi->scrub_pages = 0;
>           pi->cpu_khz = cpu_khz;
> +        pi->max_mfn = get_upper_mfn_bound();
>           arch_do_physinfo(pi);
>   
>           if ( copy_to_guest(u_sysctl, op, 1) )
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index 4d32a87cca..1e6097584b 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -36,7 +36,7 @@
>   #include "physdev.h"
>   #include "tmem.h"
>   
> -#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000F
> +#define XEN_SYSCTL_INTERFACE_VERSION 0x00000010
>   
>   /*
>    * Read console content from Xen buffer ring.
> @@ -96,14 +96,15 @@ struct xen_sysctl_physinfo {
>       uint32_t nr_nodes;    /* # nodes currently online */
>       uint32_t max_node_id; /* Largest possible node ID on this host */
>       uint32_t cpu_khz;
> +    uint32_t capabilities; /* XEN_SYSCTL_PHYSCAP_??? */
> +
>       uint64_aligned_t total_pages;
>       uint64_aligned_t free_pages;
>       uint64_aligned_t scrub_pages;
>       uint64_aligned_t outstanding_pages;
>       uint32_t hw_cap[8];
>   
> -    /* XEN_SYSCTL_PHYSCAP_??? */
> -    uint32_t capabilities;
> +    uint64_aligned_t max_mfn; /* Largest possible MFN on this host */
>   };
>   
>   /*
> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> index f8b6177c32..e813c07b22 100644
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -599,6 +599,9 @@ int prepare_ring_for_helper(struct domain *d, unsigned long gmfn,
>                               struct page_info **_page, void **_va);
>   void destroy_ring_for_helper(void **_va, struct page_info *page);
>   
> +/* Return the upper bound of MFNs, including hotplug memory. */
> +unsigned long get_upper_mfn_bound(void);
> +
>   #include <asm/flushtlb.h>
>   
>   static inline void accumulate_tlbflush(bool *need_tlbflush,
> 

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 08/11] xen/arm: move arch specific grant table bits into grant_table.c
  2017-09-25 10:00 ` [PATCH v10 08/11] xen/arm: move arch specific grant table bits into grant_table.c Juergen Gross
@ 2017-09-28  0:31   ` Julien Grall
  0 siblings, 0 replies; 35+ messages in thread
From: Julien Grall @ 2017-09-28  0:31 UTC (permalink / raw)
  To: Juergen Gross, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, jbeulich, dgdegra

Hi Juergen,

On 09/25/2017 11:00 AM, Juergen Gross wrote:
> Instead of attaching the ARM specific grant table data to the domain
> structure add it to struct grant_table. Add the needed arch functions
> to the asm-*/grant_table.h includes.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com> [non-ARM parts]

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 09/11] xen: make grant resource limits per domain
  2017-09-28  0:26   ` Julien Grall
@ 2017-09-28  7:21     ` Juergen Gross
  0 siblings, 0 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-28  7:21 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, jbeulich, dgdegra

On 28/09/17 02:26, Julien Grall wrote:
> Hi Juergen,
> 
> On 09/25/2017 11:00 AM, Juergen Gross wrote:
>> diff --git a/xen/include/asm-arm/grant_table.h
>> b/xen/include/asm-arm/grant_table.h
>> index 30db2d1616..bcdeada9ca 100644
>> --- a/xen/include/asm-arm/grant_table.h
>> +++ b/xen/include/asm-arm/grant_table.h
>> @@ -2,9 +2,11 @@
>>   #define __ASM_GRANT_TABLE_H__
>>     #include <xen/grant_table.h>
>> +#include <xen/kernel.h>
>> +#include <xen/pfn.h>
>>   #include <xen/sched.h>
>>   -#define INITIAL_NR_GRANT_FRAMES 4
>> +#define INITIAL_NR_GRANT_FRAMES 1U
>>     struct grant_table_arch {
>>       gfn_t *gfn;
>> @@ -26,9 +28,14 @@ static inline int replace_grant_supported(void)
>>       return 1;
>>   }
>>   +static inline unsigned int gnttab_dom0_max(void)
>> +{
>> +    return PFN_DOWN(_etext - _stext);
>> +}
> 
> I think you need a comment on top of this function explaining why you
> return this value. Re-using part of the comment in find_gnttab_region
> would be fine to me.

Okay.


Juergen


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-25 10:00 ` [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info Juergen Gross
  2017-09-25 11:55   ` Andrew Cooper
  2017-09-25 11:59   ` Jan Beulich
@ 2017-09-28  8:59   ` Jan Beulich
       [not found]   ` <59CCD61D0200007800180567@suse.com>
  3 siblings, 0 replies; 35+ messages in thread
From: Jan Beulich @ 2017-09-28  8:59 UTC (permalink / raw)
  To: xen-devel, Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, dgdegra

>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
>          res->b = v->vcpu_id;
>          break;
>  
> +    case 5: /* PV-specific parameters */
> +        if ( is_hvm_domain(d) || subleaf != 0 )
> +            break;
> +
> +        res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;

While preparing to commit this I wondered why this isn't just
flsl(). Can you explain this, or can I just change it?

Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
       [not found]   ` <59CCD61D0200007800180567@suse.com>
@ 2017-09-28  9:04     ` Juergen Gross
  2017-09-28  9:40       ` Jan Beulich
       [not found]       ` <59CCDFBD02000078001805E9@suse.com>
  0 siblings, 2 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-28  9:04 UTC (permalink / raw)
  To: Jan Beulich, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, dgdegra

On 28/09/17 10:59, Jan Beulich wrote:
>>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
>>          res->b = v->vcpu_id;
>>          break;
>>  
>> +    case 5: /* PV-specific parameters */
>> +        if ( is_hvm_domain(d) || subleaf != 0 )
>> +            break;
>> +
>> +        res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
> 
> While preparing to commit this I wondered why this isn't just
> flsl(). Can you explain this, or can I just change it?

It is meant to be similar to CPUID leaf 0x80000008: the width of the
max. machine address, not that of the max. MFN.


Juergen

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-28  9:04     ` Juergen Gross
@ 2017-09-28  9:40       ` Jan Beulich
       [not found]       ` <59CCDFBD02000078001805E9@suse.com>
  1 sibling, 0 replies; 35+ messages in thread
From: Jan Beulich @ 2017-09-28  9:40 UTC (permalink / raw)
  To: xen-devel, Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, dgdegra

>>> On 28.09.17 at 11:04, <jgross@suse.com> wrote:
> On 28/09/17 10:59, Jan Beulich wrote:
>>>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
>>>          res->b = v->vcpu_id;
>>>          break;
>>>  
>>> +    case 5: /* PV-specific parameters */
>>> +        if ( is_hvm_domain(d) || subleaf != 0 )
>>> +            break;
>>> +
>>> +        res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
>> 
>> While preparing to commit this I wondered why this isn't just
>> flsl(). Can you explain this, or can I just change it?
> 
> It is meant to be similar to CPUID leaf 0x80000008: the width of the
> max. machine address, not that of the max. MFN.

I don't see how this addresses the question: Just to repeat with
slightly different wording - why are you using generic_flsl() instead
of just flsl()?

Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
       [not found]       ` <59CCDFBD02000078001805E9@suse.com>
@ 2017-09-28  9:52         ` Juergen Gross
  2017-09-28 10:05           ` Jan Beulich
  0 siblings, 1 reply; 35+ messages in thread
From: Juergen Gross @ 2017-09-28  9:52 UTC (permalink / raw)
  To: Jan Beulich, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, dgdegra

On 28/09/17 11:40, Jan Beulich wrote:
>>>> On 28.09.17 at 11:04, <jgross@suse.com> wrote:
>> On 28/09/17 10:59, Jan Beulich wrote:
>>>>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
>>>> --- a/xen/arch/x86/traps.c
>>>> +++ b/xen/arch/x86/traps.c
>>>> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
>>>>          res->b = v->vcpu_id;
>>>>          break;
>>>>  
>>>> +    case 5: /* PV-specific parameters */
>>>> +        if ( is_hvm_domain(d) || subleaf != 0 )
>>>> +            break;
>>>> +
>>>> +        res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
>>>
>>> While preparing to commit this I wondered why this isn't just
>>> flsl(). Can you explain this, or can I just change it?
>>
>> It is meant to be similar to CPUID leaf 0x80000008: the width of the
>> max. machine address, not that of the max. MFN.
> 
> I don't see how this addresses the question: Just to repeat with
> slightly different wording - why are you using generic_flsl() instead
> of just flsl()?

Oh, sorry, just got the question wrong.

No specific reason for generic_flsl().

I'm just about to send the last 3 patches as a V11, so no need for you
to modify the patch.


Juergen

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info
  2017-09-28  9:52         ` Juergen Gross
@ 2017-09-28 10:05           ` Jan Beulich
  0 siblings, 0 replies; 35+ messages in thread
From: Jan Beulich @ 2017-09-28 10:05 UTC (permalink / raw)
  To: Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, julien.grall, xen-devel, dgdegra

>>> On 28.09.17 at 11:52, <jgross@suse.com> wrote:
> On 28/09/17 11:40, Jan Beulich wrote:
>>>>> On 28.09.17 at 11:04, <jgross@suse.com> wrote:
>>> On 28/09/17 10:59, Jan Beulich wrote:
>>>>>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
>>>>> --- a/xen/arch/x86/traps.c
>>>>> +++ b/xen/arch/x86/traps.c
>>>>> @@ -930,6 +930,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
> uint32_t leaf,
>>>>>          res->b = v->vcpu_id;
>>>>>          break;
>>>>>  
>>>>> +    case 5: /* PV-specific parameters */
>>>>> +        if ( is_hvm_domain(d) || subleaf != 0 )
>>>>> +            break;
>>>>> +
>>>>> +        res->a = generic_flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
>>>>
>>>> While preparing to commit this I wondered why this isn't just
>>>> flsl(). Can you explain this, or can I just change it?
>>>
>>> It is meant to be similar to CPUID leaf 0x80000008: the width of the
>>> max. machine address, not that of the max. MFN.
>> 
>> I don't see how this addresses the question: Just to repeat with
>> slightly different wording - why are you using generic_flsl() instead
>> of just flsl()?
> 
> Oh, sorry, just got the question wrong.
> 
> No specific reason for generic_flsl().
> 
> I'm just about to send the last 3 patches as a V11, so no need for you
> to modify the patch.

Resend just the single patch Julien wanted some changes in;
I'll commit the other two meanwhile (as they're independent of
the one being changed afaict).

Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h
  2017-09-25 12:01   ` Jan Beulich
@ 2017-09-28 11:50     ` George Dunlap
  2017-09-28 11:54       ` Jan Beulich
  0 siblings, 1 reply; 35+ messages in thread
From: George Dunlap @ 2017-09-28 11:50 UTC (permalink / raw)
  To: Jan Beulich, julien.grall, Juergen Gross
  Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, tim, xen-devel, dgdegra

On 09/25/2017 01:01 PM, Jan Beulich wrote:
>>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
>> Leaf 4 of the Xen-specific CPUID leaves isn't mentioned at all in
>> include/public/arch-x86/cpuid.h, the comments for leaf 5 don't tell
>> anything about the sub-leaf semantics.
>>
>> Add comments to clarify the interface.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Julien,
> 
> strictly speaking this was posted too late for 4.10, but it being
> comment changes only I think it's fine to take nevertheless?

I thought the last posting date was for *new* series -- v1 of this
series was posted back in July or something wasn't it?

Or are you speaking specifically about this patch?

 -George

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h
  2017-09-28 11:50     ` George Dunlap
@ 2017-09-28 11:54       ` Jan Beulich
  2017-09-28 19:24         ` Julien Grall
  0 siblings, 1 reply; 35+ messages in thread
From: Jan Beulich @ 2017-09-28 11:54 UTC (permalink / raw)
  To: George Dunlap
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, julien.grall, xen-devel,
	dgdegra

>>> On 28.09.17 at 13:50, <george.dunlap@citrix.com> wrote:
> On 09/25/2017 01:01 PM, Jan Beulich wrote:
>>>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
>>> Leaf 4 of the Xen-specific CPUID leaves isn't mentioned at all in
>>> include/public/arch-x86/cpuid.h, the comments for leaf 5 don't tell
>>> anything about the sub-leaf semantics.
>>>
>>> Add comments to clarify the interface.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> 
>> Acked-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Julien,
>> 
>> strictly speaking this was posted too late for 4.10, but it being
>> comment changes only I think it's fine to take nevertheless?
> 
> I thought the last posting date was for *new* series -- v1 of this
> series was posted back in July or something wasn't it?
> 
> Or are you speaking specifically about this patch?

Just this patch, but not having received an answer I took
the liberty of committing it.

Jan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 07/11] xen: delay allocation of grant table sub structures
  2017-09-25 10:00 ` [PATCH v10 07/11] xen: delay allocation of grant table sub structures Juergen Gross
  2017-09-25 10:16   ` Jan Beulich
@ 2017-09-28 18:56   ` Andrew Cooper
  2017-09-29  4:27     ` Juergen Gross
  1 sibling, 1 reply; 35+ messages in thread
From: Andrew Cooper @ 2017-09-28 18:56 UTC (permalink / raw)
  To: Juergen Gross, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, tim, ian.jackson,
	julien.grall, jbeulich, dgdegra

On 25/09/17 11:00, Juergen Gross wrote:
> Delay the allocation of the grant table sub structures in order to
> allow modifying parameters needed for sizing of these structures at a
> per domain basis. Allocate the structures and the table frames only
> from grant_table_init().
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>

I've just rebased my hypervisor and booting an HVM guest is going splat
thusly:

(XEN) Assertion 'gt->active' failed at grant_table.c:1672
(XEN) ----[ Xen-4.10-unstable  x86_64  debug=y   Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82d08020d92c>] grant_table.c#gnttab_grow_table+0x26/0x383
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor (d0v1)
(XEN) rax: 00000000ffffffea   rbx: ffff83082b783ec0   rcx: 0000000000000010
(XEN) rdx: 0000000000000020   rsi: 0000000000000001   rdi: ffff83082b782000
(XEN) rbp: ffff8300abe4fca8   rsp: ffff8300abe4fc58   r8:  0000000000000000
(XEN) r9:  deadbeefdeadf00d   r10: 0000000000000000   r11: 0000000000000282
(XEN) r12: ffff8300abe4fd10   r13: 0000000000000000   r14: ffff83082b782000
(XEN) r15: 00007fee507d3004   cr0: 0000000080050033   cr4: 00000000001526e0
(XEN) cr3: 000000083412c000   cr2: ffff880086270140
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen code around <ffff82d08020d92c> (grant_table.c#gnttab_grow_table+0x26/0x383):
(XEN)  00 48 83 7b 40 00 75 02 <0f> 0b 8b 75 c8 83 fe 03 b8 04 00 00 00 0f 47 c6
(XEN) Xen stack trace from rsp=ffff8300abe4fc58:
(XEN)    0000000800000001 0000000000000000 ffff83082b782000 ffff82d000000001
(XEN)    ffff8300abe4fca8 ffff83082b783ec0 ffff8300abe4fd10 0000000000000000
(XEN)    ffff83082b782000 00007fee507d3004 ffff8300abe4fcd8 ffff82d080216ae5
(XEN)    0000000000000001 ffff83082b782000 0000000000000000 00000000000ff000
(XEN)    ffff8300abe4fd48 ffff82d080282c31 0000000000000000 8086000000008086
(XEN)    0000000000000003 ffff880086270140 ffffffff81181268 ffffffffffffffff
(XEN)    0000000000000000 0000000000000001 0000000000000000 0000000000000000
(XEN)    ffff83082b782000 00007fee507d3004 ffff8300abe4fe68 ffff82d08021ecd3
(XEN)    ffff8300abf7d000 ffff8308373eb000 0000000000000000 ffff8300abf7d000
(XEN)    ffff8300abe4fd98 ffff82d08028a70f 00000000ffffffff ffff8308373e0000
(XEN)    ffff8300abe4fe68 ffff82d08028bca1 000000000000e033 0000000000010246
(XEN)    0000000100000001 0000000000000000 00000000000ff000 ffff82d08035285e
(XEN)    ffff82d08057aa88 ffff8300abe4ffff ffff8300abe4fe68 ffff82d080357a95
(XEN)    ffff880087e2aa68 00000000000fefff 0000000000000246 00007fee4f7f2537
(XEN)    0000000000000100 00007fee4f7f2537 0000000000000033 0000000000000246
(XEN)    00007ffdef7c6fa8 ffff8300abe4ff18 ffff8300abf7d000 000000000000000c
(XEN)    ffff82d08021db9d deadbeefdeadf00d ffff8300abe4ff08 ffff82d0803574fe
(XEN)    0200008700000001 0000000000000007 00007fee507d3004 deadbeefdeadf00d
(XEN)    deadbeefdeadf00d deadbeefdeadf00d ffff8300abf7d000 ffff880086270140
(XEN)    ffff8300abe4ff08 ffff82d0802a03f5 ffff8300abe4fef8 ffff82d080237abe
(XEN) Xen call trace:
(XEN)    [<ffff82d08020d92c>] grant_table.c#gnttab_grow_table+0x26/0x383
(XEN)    [<ffff82d080216ae5>] gnttab_map_frame+0x11a/0x1e6
(XEN)    [<ffff82d080282c31>] xenmem_add_to_physmap_one+0xda/0x40c
(XEN)    [<ffff82d08021ecd3>] do_memory_op+0x1136/0x2573
(XEN)    [<ffff82d0803574fe>] pv_hypercall+0x1ef/0x42d
(XEN)    [<ffff82d08035bfd6>] x86_64/entry.S#test_all_events+0/0x30
(XEN) 
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion 'gt->active' failed at grant_table.c:1672
(XEN) ****************************************

I've not taken a new toolstack (as I'm unable to atm), but it looks like
the correctness of hypervisor behaviour might now depend on toolstack
behaviour, which is distinctly suboptimal.

~Andrew

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h
  2017-09-28 11:54       ` Jan Beulich
@ 2017-09-28 19:24         ` Julien Grall
  0 siblings, 0 replies; 35+ messages in thread
From: Julien Grall @ 2017-09-28 19:24 UTC (permalink / raw)
  To: Jan Beulich, George Dunlap
  Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, xen-devel, dgdegra

On 09/28/2017 12:54 PM, Jan Beulich wrote:
>>>> On 28.09.17 at 13:50, <george.dunlap@citrix.com> wrote:
>> On 09/25/2017 01:01 PM, Jan Beulich wrote:
>>>>>> On 25.09.17 at 12:00, <jgross@suse.com> wrote:
>>>> Leaf 4 of the Xen-specific CPUID leaves isn't mentioned at all in
>>>> include/public/arch-x86/cpuid.h, the comments for leaf 5 don't tell
>>>> anything about the sub-leaf semantics.
>>>>
>>>> Add comments to clarify the interface.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> Acked-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> Julien,
>>>
>>> strictly speaking this was posted too late for 4.10, but it being
>>> comment changes only I think it's fine to take nevertheless?
>>
>> I thought the last posting date was for *new* series -- v1 of this
>> series was posted back in July or something wasn't it?
>>
>> Or are you speaking specifically about this patch?
> 
> Just this patch, but not having received an answer I took
> the liberty of committing it.

Well, I have been on conference in California for the past week. So I 
would have appreciated, if not waiting a few days, a quick ping on IRC.

Cheers,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [PATCH v10 07/11] xen: delay allocation of grant table sub structures
  2017-09-28 18:56   ` Andrew Cooper
@ 2017-09-29  4:27     ` Juergen Gross
  0 siblings, 0 replies; 35+ messages in thread
From: Juergen Gross @ 2017-09-29  4:27 UTC (permalink / raw)
  To: Andrew Cooper, xen-devel
  Cc: sstabellini, wei.liu2, George.Dunlap, tim, ian.jackson,
	julien.grall, jbeulich, dgdegra

On 28/09/17 20:56, Andrew Cooper wrote:
> On 25/09/17 11:00, Juergen Gross wrote:
>> Delay the allocation of the grant table sub structures in order to
>> allow modifying parameters needed for sizing of these structures at a
>> per domain basis. Allocate the structures and the table frames only
>> from grant_table_init().
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
> 
> I've just rebased my hypervisor and booting an HVM guest is going splat
> thusly:
> 
> (XEN) Assertion 'gt->active' failed at grant_table.c:1672
> (XEN) ----[ Xen-4.10-unstable  x86_64  debug=y   Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82d08020d92c>] grant_table.c#gnttab_grow_table+0x26/0x383
> (XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor (d0v1)
> (XEN) rax: 00000000ffffffea   rbx: ffff83082b783ec0   rcx: 0000000000000010
> (XEN) rdx: 0000000000000020   rsi: 0000000000000001   rdi: ffff83082b782000
> (XEN) rbp: ffff8300abe4fca8   rsp: ffff8300abe4fc58   r8:  0000000000000000
> (XEN) r9:  deadbeefdeadf00d   r10: 0000000000000000   r11: 0000000000000282
> (XEN) r12: ffff8300abe4fd10   r13: 0000000000000000   r14: ffff83082b782000
> (XEN) r15: 00007fee507d3004   cr0: 0000000080050033   cr4: 00000000001526e0
> (XEN) cr3: 000000083412c000   cr2: ffff880086270140
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen code around <ffff82d08020d92c> (grant_table.c#gnttab_grow_table+0x26/0x383):
> (XEN)  00 48 83 7b 40 00 75 02 <0f> 0b 8b 75 c8 83 fe 03 b8 04 00 00 00 0f 47 c6
> (XEN) Xen stack trace from rsp=ffff8300abe4fc58:
> (XEN)    0000000800000001 0000000000000000 ffff83082b782000 ffff82d000000001
> (XEN)    ffff8300abe4fca8 ffff83082b783ec0 ffff8300abe4fd10 0000000000000000
> (XEN)    ffff83082b782000 00007fee507d3004 ffff8300abe4fcd8 ffff82d080216ae5
> (XEN)    0000000000000001 ffff83082b782000 0000000000000000 00000000000ff000
> (XEN)    ffff8300abe4fd48 ffff82d080282c31 0000000000000000 8086000000008086
> (XEN)    0000000000000003 ffff880086270140 ffffffff81181268 ffffffffffffffff
> (XEN)    0000000000000000 0000000000000001 0000000000000000 0000000000000000
> (XEN)    ffff83082b782000 00007fee507d3004 ffff8300abe4fe68 ffff82d08021ecd3
> (XEN)    ffff8300abf7d000 ffff8308373eb000 0000000000000000 ffff8300abf7d000
> (XEN)    ffff8300abe4fd98 ffff82d08028a70f 00000000ffffffff ffff8308373e0000
> (XEN)    ffff8300abe4fe68 ffff82d08028bca1 000000000000e033 0000000000010246
> (XEN)    0000000100000001 0000000000000000 00000000000ff000 ffff82d08035285e
> (XEN)    ffff82d08057aa88 ffff8300abe4ffff ffff8300abe4fe68 ffff82d080357a95
> (XEN)    ffff880087e2aa68 00000000000fefff 0000000000000246 00007fee4f7f2537
> (XEN)    0000000000000100 00007fee4f7f2537 0000000000000033 0000000000000246
> (XEN)    00007ffdef7c6fa8 ffff8300abe4ff18 ffff8300abf7d000 000000000000000c
> (XEN)    ffff82d08021db9d deadbeefdeadf00d ffff8300abe4ff08 ffff82d0803574fe
> (XEN)    0200008700000001 0000000000000007 00007fee507d3004 deadbeefdeadf00d
> (XEN)    deadbeefdeadf00d deadbeefdeadf00d ffff8300abf7d000 ffff880086270140
> (XEN)    ffff8300abe4ff08 ffff82d0802a03f5 ffff8300abe4fef8 ffff82d080237abe
> (XEN) Xen call trace:
> (XEN)    [<ffff82d08020d92c>] grant_table.c#gnttab_grow_table+0x26/0x383
> (XEN)    [<ffff82d080216ae5>] gnttab_map_frame+0x11a/0x1e6
> (XEN)    [<ffff82d080282c31>] xenmem_add_to_physmap_one+0xda/0x40c
> (XEN)    [<ffff82d08021ecd3>] do_memory_op+0x1136/0x2573
> (XEN)    [<ffff82d0803574fe>] pv_hypercall+0x1ef/0x42d
> (XEN)    [<ffff82d08035bfd6>] x86_64/entry.S#test_all_events+0/0x30
> (XEN) 
> (XEN) 
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Assertion 'gt->active' failed at grant_table.c:1672
> (XEN) ****************************************
> 
> I've not taken a new toolstack (as I'm unable to atm), but it looks like
> the correctness of hypervisor behaviour might now depend on toolstack
> behaviour, which is distinctly suboptimal.

The set limits domctl is now mandatory.

I'll send a patch which will just return an error instead of breaking
the system.


Juergen


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2017-09-29  4:28 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-25 10:00 [PATCH v10 00/11] xen: better grant v2 support Juergen Gross
2017-09-25 10:00 ` [PATCH v10 01/11] xen: add function for obtaining highest possible memory address Juergen Gross
2017-09-25 10:19   ` Jan Beulich
2017-09-28  0:29   ` Julien Grall
2017-09-25 10:00 ` [PATCH v10 02/11] libxc: add libxc support for setting grant table resource limits Juergen Gross
2017-09-25 10:00 ` [PATCH v10 03/11] tools: set grant limits for xenstore stubdom Juergen Gross
2017-09-25 10:00 ` [PATCH v10 04/11] libxl: add max possible mfn to libxl_physinfo Juergen Gross
2017-09-25 10:00 ` [PATCH v10 05/11] xl: add global grant limit config items Juergen Gross
2017-09-25 10:00 ` [PATCH v10 06/11] libxl: add libxl support for setting grant table resource limits Juergen Gross
2017-09-25 10:00 ` [PATCH v10 07/11] xen: delay allocation of grant table sub structures Juergen Gross
2017-09-25 10:16   ` Jan Beulich
2017-09-28 18:56   ` Andrew Cooper
2017-09-29  4:27     ` Juergen Gross
2017-09-25 10:00 ` [PATCH v10 08/11] xen/arm: move arch specific grant table bits into grant_table.c Juergen Gross
2017-09-28  0:31   ` Julien Grall
2017-09-25 10:00 ` [PATCH v10 09/11] xen: make grant resource limits per domain Juergen Gross
2017-09-25 11:49   ` Jan Beulich
2017-09-28  0:26   ` Julien Grall
2017-09-28  7:21     ` Juergen Gross
2017-09-25 10:00 ` [PATCH v10 10/11] xen: add new Xen cpuid node for max address width info Juergen Gross
2017-09-25 11:55   ` Andrew Cooper
2017-09-25 12:00     ` Juergen Gross
2017-09-25 12:02       ` Andrew Cooper
2017-09-25 12:03       ` Jan Beulich
2017-09-25 11:59   ` Jan Beulich
2017-09-28  8:59   ` Jan Beulich
     [not found]   ` <59CCD61D0200007800180567@suse.com>
2017-09-28  9:04     ` Juergen Gross
2017-09-28  9:40       ` Jan Beulich
     [not found]       ` <59CCDFBD02000078001805E9@suse.com>
2017-09-28  9:52         ` Juergen Gross
2017-09-28 10:05           ` Jan Beulich
2017-09-25 10:00 ` [PATCH v10 11/11] xen: add some comments in include/public/arch-x86/cpuid.h Juergen Gross
2017-09-25 12:01   ` Jan Beulich
2017-09-28 11:50     ` George Dunlap
2017-09-28 11:54       ` Jan Beulich
2017-09-28 19:24         ` Julien Grall

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.