From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yu, Zhang" Subject: Re: [V9 0/3] Refactor ioreq server for better performance. Date: Thu, 31 Dec 2015 17:32:34 +0800 Message-ID: <5684F632.8020009@linux.intel.com> References: <1450145110-2860-1-git-send-email-shuai.ruan@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1450145110-2860-1-git-send-email-shuai.ruan@linux.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Shuai Ruan , xen-devel@lists.xen.org Cc: kevin.tian@intel.com, wei.liu2@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, keir@xen.org List-Id: xen-devel@lists.xenproject.org Shuai, thank you very much for helping me push these patches! And sorry for the delay due to my illness. Now I'm back and will pick this up. :) B.R. Yu On 12/15/2015 10:05 AM, Shuai Ruan wrote: > From: Yu Zhang ng the > > 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 v9: > 1> Change order of patch 2 and patch3. > 2> Intruduce a const static array before hvm_ioreq_server_alloc_rangesets(). > 3> Coding style changes. > > 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. > Refactor rangeset structure for better performance. > Differentiate IO/mem resources tracked by ioreq server > > tools/libxc/include/xenctrl.h | 31 +++++++++++++++ > tools/libxc/xc_domain.c | 61 ++++++++++++++++++++++++++++++ > xen/arch/x86/hvm/hvm.c | 43 ++++++++++++++------- > xen/common/rangeset.c | 82 +++++++++++++++++++++++++++++----------- > xen/include/asm-x86/hvm/domain.h | 4 +- > xen/include/public/hvm/hvm_op.h | 1 + > 6 files changed, 185 insertions(+), 37 deletions(-) >