From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: xen-devel@lists.xen.org, Paul.Durrant@citrix.com,
ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
ian.campbell@citrix.com, wei.liu2@citrix.com, keir@xen.org,
jbeulich@suse.com, andrew.cooper3@citrix.com
Cc: kevin.tian@intel.com, zhiyuan.lv@intel.com
Subject: [PATCH v8 0/3] Refactor ioreq server for better performance.
Date: Sun, 23 Aug 2015 17:33:15 +0800 [thread overview]
Message-ID: <1440322398-8779-1-git-send-email-yu.c.zhang@linux.intel.com> (raw)
XenGT leverages ioreq server to track and forward the accesses to
GPU I/O resources, e.g. the PPGTT(per-process graphic translation
tables). Currently, ioreq server uses rangeset to track the BDF/
PIO/MMIO ranges to be emulated. To select an ioreq server, the
rangeset is searched to see if the I/O range is recorded. However,
traversing the link list inside rangeset could be time consuming
when number of ranges is too high. On HSW platform, number of PPGTTs
for each vGPU could be several hundred. On BDW, this value could
be several thousand. This patch series refactored rangeset to base
it on red-back tree, so that the searching would be more efficient.
Besides, this patchset also splits the tracking of MMIO and guest
ram ranges into different rangesets. And to accommodate more ranges,
limitation of the number of ranges in an ioreq server, MAX_NR_IO_RANGES
is changed - future patches might be provided to tune this with other
approaches.
Changes in v8:
Use a clearer API name to map/unmap the write-protected memory in
ioreq server.
Changes in v7:
1> Coding style changes;
2> Fix a typo in hvm_select_ioreq_server().
Changes in v6:
Break the identical relationship between ioreq type and rangeset
index inside ioreq server.
Changes in v5:
1> Use gpfn, instead of gpa to track guest write-protected pages;
2> Remove redundant conditional statement in routine find_range().
Changes in v4:
Keep the name HVMOP_IO_RANGE_MEMORY for MMIO resources, and add
a new one, HVMOP_IO_RANGE_WP_MEM, for write-protected memory.
Changes in v3:
1> Use a seperate rangeset for guest ram pages in ioreq server;
2> Refactor rangeset, instead of introduce a new data structure.
Changes in v2:
1> Split the original patch into 2;
2> Take Paul Durrant's comments:
a> Add a name member in the struct rb_rangeset, and use the 'q'
debug key to dump the ranges in ioreq server;
b> Keep original routine names for hvm ioreq server;
c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq server.
Yu Zhang (3):
Remove identical relationship between ioreq type and rangeset type.
Differentiate IO/mem resources tracked by ioreq server
Refactor rangeset structure for better performance.
tools/libxc/include/xenctrl.h | 31 +++++++++++++++
tools/libxc/xc_domain.c | 61 ++++++++++++++++++++++++++++++
xen/arch/x86/hvm/hvm.c | 39 ++++++++++++++-----
xen/common/rangeset.c | 82 +++++++++++++++++++++++++++++-----------
xen/include/asm-x86/hvm/domain.h | 4 +-
xen/include/public/hvm/hvm_op.h | 1 +
6 files changed, 184 insertions(+), 34 deletions(-)
--
1.9.1
next reply other threads:[~2015-08-23 9:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-23 9:33 Yu Zhang [this message]
2015-08-23 9:33 ` [PATCH v8 1/3] Remove identical relationship between ioreq type and rangeset type Yu Zhang
2015-08-31 12:06 ` Jan Beulich
2015-08-23 9:33 ` [PATCH v8 2/3] Differentiate IO/mem resources tracked by ioreq server Yu Zhang
2015-08-25 9:40 ` Wei Liu
2015-08-28 3:11 ` Yu, Zhang
2015-08-28 8:38 ` Jan Beulich
2015-08-28 9:55 ` Yu, Zhang
2015-09-01 15:38 ` Ian Campbell
2015-08-31 12:18 ` Jan Beulich
2015-08-23 9:33 ` [PATCH v8 3/3] Refactor rangeset structure for better performance Yu Zhang
2015-08-31 12:29 ` Jan Beulich
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=1440322398-8779-1-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).