From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: xen-devel@lists.xen.org
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
ian.jackson@eu.citrix.com, Paul.Durrant@citrix.com,
zhiyuan.lv@intel.com, jbeulich@suse.com, wei.liu2@citrix.com
Subject: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.
Date: Fri, 29 Jan 2016 18:45:14 +0800 [thread overview]
Message-ID: <1454064314-7799-4-git-send-email-yu.c.zhang@linux.intel.com> (raw)
In-Reply-To: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.com>
A new parameter - max_wp_ram_ranges is added to set the upper limit
of write-protected ram ranges to be tracked inside one ioreq server
rangeset.
Ioreq server uses a group of rangesets to track the I/O or memory
resources to be emulated. Default limit of ranges that one rangeset
can allocate is set to a small value, due to the fact that these ranges
are allocated in xen heap. Yet for the write-protected ram ranges,
there are circumstances under which the upper limit inside one rangeset
should exceed the default one. E.g. in XenGT, when tracking the PPGTTs(
per-process graphic translation tables) on Intel BDW platforms, number
of page tables concerned will be of several thousand.
For XenGT runing on Intel BDW platform, 8192 is a suggested value for
this parameter in most cases. But users who set his item explicitly
are also supposed to know the specific scenarios that necessitate this
configuration. Especially when this parameter is used:
1> for virtual devices other than vGPUs in XenGT;
2> for XenGT, there also might be some extreme cases, e.g. too many
graphic related applications in one VM, which create a great deal of
per-process graphic translation tables;
3> for XenGT, future cpu platforms which provide even more per-process
graphic translation tables.
Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
---
docs/man/xl.cfg.pod.5 | 26 ++++++++++++++++++++++++++
tools/libxl/libxl.h | 5 +++++
tools/libxl/libxl_dom.c | 3 +++
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 17 +++++++++++++++++
xen/arch/x86/hvm/hvm.c | 7 ++++++-
xen/include/public/hvm/params.h | 5 ++++-
7 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 8899f75..c294fd3 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -962,6 +962,32 @@ FIFO-based event channel ABI support up to 131,071 event channels.
Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
x86).
+=item B<max_wp_ram_ranges=N>
+
+Limit the maximum write-protected ram ranges that can be tracked
+inside one ioreq server rangeset.
+
+Ioreq server uses a group of rangesets to track the I/O or memory
+resources to be emulated. Default limit of ranges that one rangeset
+can allocate is set to a small value, due to the fact that these
+ranges are allocated in xen heap. Yet for the write-protected ram
+ranges, there are circumstances under which the upper limit inside
+one rangeset should exceed the default one. E.g. in Intel GVT-g,
+when tracking the PPGTT(per-process graphic translation tables) on
+Intel broadwell platforms, the number of page tables concerned will
+be of several thousand.
+
+For Intel GVT-g broadwell platform, 8192 is a suggested value for
+this parameter in most cases. But users who set his item explicitly
+are also supposed to know the specific scenarios that necessitate
+this configuration. Especially when this parameter is used:
+1> for virtual devices other than vGPU in GVT-g;
+2> for GVT-g, there also might be some extreme cases, e.g. too many
+graphic related applications in one VM, which create a great deal of
+per-process graphic translation tables;
+3> for GVT-g, future cpu platforms which provide even more per-process
+graphic translation tables.
+
=back
=head2 Paravirtualised (PV) Guest Specific Options
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index fa87f53..18828c5 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -136,6 +136,11 @@
#define LIBXL_HAVE_BUILDINFO_EVENT_CHANNELS 1
/*
+ * libxl_domain_build_info has the u.hvm.max_wp_ram_ranges field.
+ */
+#define LIBXL_HAVE_BUILDINFO_HVM_MAX_WP_RAM_RANGES 1
+
+/*
* libxl_domain_build_info has the u.hvm.ms_vm_genid field.
*/
#define LIBXL_HAVE_BUILDINFO_HVM_MS_VM_GENID 1
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2269998..54173cb 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -288,6 +288,9 @@ static void hvm_set_conf_params(xc_interface *handle, uint32_t domid,
libxl_defbool_val(info->u.hvm.nested_hvm));
xc_hvm_param_set(handle, domid, HVM_PARAM_ALTP2M,
libxl_defbool_val(info->u.hvm.altp2m));
+ if (info->u.hvm.max_wp_ram_ranges > 0)
+ xc_hvm_param_set(handle, domid, HVM_PARAM_MAX_WP_RAM_RANGES,
+ info->u.hvm.max_wp_ram_ranges);
}
int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 9ad7eba..9185014 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -518,6 +518,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("serial_list", libxl_string_list),
("rdm", libxl_rdm_reserve),
("rdm_mem_boundary_memkb", MemKB),
+ ("max_wp_ram_ranges", uint64),
])),
("pv", Struct(None, [("kernel", string),
("slack_memkb", MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 25507c7..0c19dee 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -35,6 +35,7 @@
#include <inttypes.h>
#include <limits.h>
#include <xen/hvm/e820.h>
+#include <xenctrl.h>
#include "libxl.h"
#include "libxl_utils.h"
@@ -1626,6 +1627,22 @@ static void parse_config_data(const char *config_source,
if (!xlu_cfg_get_long (config, "rdm_mem_boundary", &l, 0))
b_info->u.hvm.rdm_mem_boundary_memkb = l * 1024;
+
+ if (!xlu_cfg_get_long (config, "max_wp_ram_ranges", &l, 0)) {
+ uint64_t nr_pages = (b_info->max_memkb << 10) >> XC_PAGE_SHIFT;
+
+ /* Due to rangeset's ability to combine continuous ranges, this
+ * parameter shall not be configured with values greater than half
+ * of the number of VM's page frames. It also shall not exceed 4G,
+ * because of the limitation from the rangeset side. */
+ if (l > (nr_pages / 2) || l > UINT32_MAX) {
+ fprintf(stderr, "ERROR: Invalid value for \"max_wp_ram_ranges\". "
+ "Shall not exceed %ld or 4G.\n", nr_pages / 2);
+ exit(1);
+ }
+ b_info->u.hvm.max_wp_ram_ranges = l;
+ }
+
break;
case LIBXL_DOMAIN_TYPE_PV:
{
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d998f..7339833 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -940,6 +940,8 @@ static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
{
unsigned int i;
int rc;
+ unsigned int max_wp_ram_ranges =
+ s->domain->arch.hvm_domain.params[HVM_PARAM_MAX_WP_RAM_RANGES];
if ( is_default )
goto done;
@@ -962,7 +964,10 @@ static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
if ( !s->range[i] )
goto fail;
- rangeset_limit(s->range[i], MAX_NR_IO_RANGES);
+ rangeset_limit(s->range[i],
+ ((i == HVMOP_IO_RANGE_WP_MEM) ?
+ max_wp_ram_ranges :
+ MAX_NR_IO_RANGES));
}
done:
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 81f9451..ab3b11d 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -210,6 +210,9 @@
/* Boolean: Enable altp2m */
#define HVM_PARAM_ALTP2M 35
-#define HVM_NR_PARAMS 36
+/* Max write-protected ram ranges to be tracked in one ioreq server rangeset */
+#define HVM_PARAM_MAX_WP_RAM_RANGES 36
+
+#define HVM_NR_PARAMS 37
#endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
--
1.9.1
next prev parent reply other threads:[~2016-01-29 10:45 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 10:45 [PATCH v12 0/3] Refactor ioreq server for better performance Yu Zhang
2016-01-29 10:45 ` [PATCH v12 1/3] Refactor rangeset structure " Yu Zhang
2016-01-29 10:45 ` [PATCH v12 2/3] Differentiate IO/mem resources tracked by ioreq server Yu Zhang
2016-01-29 10:45 ` Yu Zhang [this message]
2016-01-29 16:33 ` [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges Jan Beulich
2016-01-30 14:38 ` Yu, Zhang
2016-02-01 7:52 ` Jan Beulich
2016-02-01 12:02 ` Wei Liu
2016-02-01 12:15 ` Jan Beulich
2016-02-01 12:49 ` Wei Liu
2016-02-01 13:07 ` Jan Beulich
2016-02-01 15:14 ` Yu, Zhang
2016-02-01 16:16 ` Jan Beulich
2016-02-01 16:33 ` Yu, Zhang
2016-02-01 16:19 ` Yu, Zhang
2016-02-01 16:35 ` Jan Beulich
2016-02-01 16:37 ` Yu, Zhang
2016-02-01 17:05 ` Ian Jackson
2016-02-02 8:04 ` Yu, Zhang
2016-02-02 11:51 ` Wei Liu
2016-02-02 13:56 ` Yu, Zhang
2016-02-02 10:32 ` Jan Beulich
2016-02-02 10:56 ` Yu, Zhang
2016-02-02 11:12 ` Jan Beulich
2016-02-02 14:01 ` Yu, Zhang
2016-02-02 14:42 ` Jan Beulich
2016-02-02 15:00 ` Yu, Zhang
2016-02-02 15:21 ` Jan Beulich
2016-02-02 15:19 ` Yu, Zhang
2016-02-03 7:10 ` Yu, Zhang
2016-02-03 8:32 ` Jan Beulich
2016-02-03 12:20 ` Paul Durrant
2016-02-03 12:35 ` Jan Beulich
2016-02-03 12:50 ` Paul Durrant
2016-02-03 13:00 ` Jan Beulich
2016-02-03 13:07 ` Paul Durrant
2016-02-03 13:17 ` Jan Beulich
2016-02-03 13:18 ` Paul Durrant
2016-02-03 14:43 ` Ian Jackson
2016-02-03 15:10 ` Paul Durrant
2016-02-03 17:50 ` George Dunlap
2016-02-04 8:50 ` Yu, Zhang
2016-02-03 17:41 ` George Dunlap
2016-02-03 18:21 ` George Dunlap
2016-02-03 18:26 ` George Dunlap
2016-02-03 18:39 ` Andrew Cooper
2016-02-03 19:12 ` George Dunlap
2016-02-04 8:51 ` Yu, Zhang
2016-02-04 10:49 ` George Dunlap
2016-02-04 11:08 ` Ian Campbell
2016-02-04 11:19 ` Ian Campbell
2016-02-04 8:50 ` Yu, Zhang
2016-02-04 9:28 ` Paul Durrant
2016-02-04 9:38 ` Yu, Zhang
2016-02-04 9:49 ` Paul Durrant
2016-02-04 10:34 ` Jan Beulich
2016-02-04 13:33 ` Ian Jackson
2016-02-04 13:47 ` Paul Durrant
2016-02-04 14:12 ` Jan Beulich
2016-02-04 14:25 ` Paul Durrant
2016-02-04 15:06 ` Ian Jackson
2016-02-04 15:51 ` Paul Durrant
2016-02-05 3:47 ` Tian, Kevin
2016-02-05 3:35 ` Tian, Kevin
2016-02-04 14:08 ` Jan Beulich
2016-02-04 17:12 ` George Dunlap
2016-02-05 4:18 ` Tian, Kevin
2016-02-05 8:41 ` Yu, Zhang
2016-02-05 8:32 ` Jan Beulich
2016-02-05 9:24 ` Paul Durrant
2016-02-05 10:41 ` Jan Beulich
2016-02-05 11:14 ` George Dunlap
2016-02-05 11:24 ` Paul Durrant
2016-02-16 7:22 ` Tian, Kevin
2016-02-16 8:50 ` Paul Durrant
2016-02-16 10:33 ` Jan Beulich
2016-02-16 11:11 ` Paul Durrant
2016-02-17 3:18 ` Tian, Kevin
2016-02-17 8:58 ` Paul Durrant
2016-02-17 9:32 ` Jan Beulich
2016-02-17 9:58 ` Tian, Kevin
2016-02-17 10:03 ` Paul Durrant
2016-02-17 10:22 ` Jan Beulich
2016-02-17 10:24 ` Paul Durrant
2016-02-17 10:25 ` Tian, Kevin
2016-02-17 11:01 ` George Dunlap
2016-02-17 11:12 ` Paul Durrant
2016-02-22 15:56 ` George Dunlap
2016-02-22 16:02 ` Paul Durrant
2016-02-22 16:45 ` George Dunlap
2016-02-22 17:01 ` Paul Durrant
2016-02-22 17:23 ` George Dunlap
2016-02-22 17:34 ` Paul Durrant
2016-02-05 8:41 ` Yu, Zhang
2016-02-04 11:06 ` George Dunlap
2016-02-05 2:01 ` Zhiyuan Lv
2016-02-05 3:44 ` Tian, Kevin
2016-02-05 8:38 ` Jan Beulich
2016-02-05 11:05 ` George Dunlap
2016-02-05 15:13 ` Zhiyuan Lv
2016-02-05 20:14 ` George Dunlap
2016-02-05 8:40 ` Yu, Zhang
2016-02-04 10:06 ` Ian Campbell
2016-02-05 3:31 ` Tian, Kevin
2016-02-02 11:31 ` Andrew Cooper
2016-02-02 11:43 ` Jan Beulich
2016-02-02 14:20 ` Andrew Cooper
2016-02-01 11:57 ` Wei Liu
2016-02-01 15:15 ` Yu, Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1454064314-7799-4-git-send-email-yu.c.zhang@linux.intel.com \
--to=yu.c.zhang@linux.intel.com \
--cc=Paul.Durrant@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=kevin.tian@intel.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=zhiyuan.lv@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).