From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v6][PATCH 0/7] xen: reserve RMRR to avoid conflicting MMIO/RAM Date: Thu, 11 Sep 2014 09:38:24 +0800 Message-ID: <5410FD10.1020603@intel.com> References: <1410328190-6372-1-git-send-email-tiejun.chen@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Tian, Kevin" , "JBeulich@suse.com" , "ian.campbell@citrix.com" , "ian.jackson@eu.citrix.com" , "stefano.stabellini@eu.citrix.com" , "Zhang, Yang Z" Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 2014/9/11 5:44, Tian, Kevin wrote: >> From: Chen, Tiejun >> Sent: Tuesday, September 09, 2014 10:50 PM >> > > currently the confliction is detected absolutely. Do we need a way to allow > the confliction if there is no device assigned at all? How to handle a hot-plug case when guest already boot? I think it may not be worth distinguishing such fine gain, things will be becoming complicated. Thanks Tiejun > >> v6: >> >> * Jan cleanup to regenerate one patch to replace the two original patches >> then rebase the others. >> * Refine all patches short/long logs. >> * Replace those info with 'reserved device memory maps' and s/RMRR/RDM. >> * Fix some code styles. >> * Fix one interation error when we grab e820 info >> This is not valid when j == nr - 1 (last iteration). >> * Cleanup some codes. >> * One comment to introduce a new field, nr_reserved_device_memory_map >> libxc/hvm_info_table, is still pending to wait the tools maintainer's >> further comment. >> >> v5: >> >> * Add patch #2 to introduce a global count, acpi_rmrr_unit_entries. >> * Refine hypercall return value to make sure the caller can distinguish >> clearly between "xen filled in N entries" and "xen said you need N >> entries for all information". >> * Refine some structures >> * Then Rebase >> >> v4: >> >> * Drop the original patch #1. Instead, we use acpi_rmrr_units to get >> rmrr info directly. >> * Refine the hypercall definition to make sure we can use it safely. >> * Introduce introduce nr_reserved_device_memory_map in hvm_info_table, >> then we can avoid issue unnecessary hypercall, even we can know >> current RMRR entries to issue hypercall one time. >> * Cleanup and rebase >> >> v3: >> >> * Use XENMEM_reserved_device_memory_map to replace >> XENMEM_RMRR_memory_map >> * Then rebase all patches >> >> v2: >> >> * Don't use e820map to define RMRR maps directly to avoid any confusion. >> * In patch #3 we introduce construct_rmrr_e820_maps() to check if we can >> insert RMRR maps and then we will sort all e820 entries. >> * Clean patch #4 >> * In patch #5 we reuse check_mmio_hole() to check if current mmio range is >> fine to RMRR maps. If not, we just issue error to notify the user since >> mostly mmio should be configured again. >> >> While we work for supporting RMRR mapping for Windows GFX driver in case >> shared table, >> >> http://osdir.com/ml/general/2014-07/msg55347.html >> http://osdir.com/ml/general/2014-07/msg55348.html >> >> we realize we should reserve RMRR range to avoid any potential MMIO/RAM >> overlap with our discussion so here these preliminary patches are intended >> to cover this. >> >> ---------------------------------------------------------------- >> Jan Beulich (1): >> introduce XENMEM_reserved_device_memory_map >> >> Tiejun Chen (6): >> tools/libxc: introduce hypercall for xc_reserved_device_memory_map >> tools/libxc: check if mmio BAR is out of reserved device memory maps >> libxc/hvm_info_table: introduce a new field >> nr_reserved_device_memory_map >> hvmloader: introduce hypercall for xc_reserved_device_memory_map >> hvmloader: check to reserved device memory maps in e820 >> xen/vtd: make USB RMRR mapping safe >> >> tools/firmware/hvmloader/e820.c | 100 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> ++++++++++++++++++++++++++++++++++++ >> tools/firmware/hvmloader/util.c | 22 ++++++++++++++++++++++ >> tools/firmware/hvmloader/util.h | 3 +++ >> tools/libxc/xc_domain.c | 29 >> +++++++++++++++++++++++++++++ >> tools/libxc/xc_hvm_build_x86.c | 82 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> ++++++++++++++++-- >> tools/libxc/xenctrl.h | 4 ++++ >> xen/common/compat/memory.c | 52 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++ >> xen/common/memory.c | 49 >> +++++++++++++++++++++++++++++++++++++++++++++++++ >> xen/drivers/passthrough/iommu.c | 10 ++++++++++ >> xen/drivers/passthrough/vtd/dmar.c | 17 +++++++++++++++++ >> xen/drivers/passthrough/vtd/extern.h | 1 + >> xen/drivers/passthrough/vtd/iommu.c | 9 +-------- >> xen/include/public/hvm/hvm_info_table.h | 3 +++ >> xen/include/public/memory.h | 24 >> +++++++++++++++++++++++- >> xen/include/xen/iommu.h | 4 ++++ >> xen/include/xlat.lst | 3 ++- >> 16 files changed, 400 insertions(+), 12 deletions(-) >> >> Thanks >> Tiejun >