All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>,
	"Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [v6][PATCH 0/7] xen: reserve RMRR to avoid conflicting MMIO/RAM
Date: Thu, 11 Sep 2014 09:38:24 +0800	[thread overview]
Message-ID: <5410FD10.1020603@intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12607C2D4@SHSMSX101.ccr.corp.intel.com>

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
>

  reply	other threads:[~2014-09-11  1:38 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10  5:49 [v6][PATCH 0/7] xen: reserve RMRR to avoid conflicting MMIO/RAM Tiejun Chen
2014-09-10  5:49 ` [v6][PATCH 1/7] introduce XENMEM_reserved_device_memory_map Tiejun Chen
2014-09-10 21:34   ` Tian, Kevin
2014-09-10  5:49 ` [v6][PATCH 2/7] tools/libxc: introduce hypercall for xc_reserved_device_memory_map Tiejun Chen
2014-09-11 15:21   ` Jan Beulich
2014-09-11 15:23     ` Ian Campbell
2014-09-11 15:55     ` Andrew Cooper
2014-09-12  2:43     ` Chen, Tiejun
2014-09-12  6:20       ` Jan Beulich
2014-09-10  5:49 ` [v6][PATCH 3/7] tools/libxc: check if mmio BAR is out of reserved device memory maps Tiejun Chen
2014-09-10 21:37   ` Tian, Kevin
2014-09-11  1:14     ` Chen, Tiejun
2014-09-11 22:55       ` Tian, Kevin
2014-09-11 15:38   ` Jan Beulich
2014-09-12  2:56     ` Chen, Tiejun
2014-09-12  6:19     ` Jan Beulich
2014-09-10  5:49 ` [v6][PATCH 4/7] libxc/hvm_info_table: introduce a new field nr_reserved_device_memory_map Tiejun Chen
2014-09-10 21:39   ` Tian, Kevin
2014-09-11  1:16     ` Chen, Tiejun
2014-09-10  5:49 ` [v6][PATCH 5/7] hvmloader: introduce hypercall for xc_reserved_device_memory_map Tiejun Chen
2014-09-10 21:41   ` Tian, Kevin
2014-09-11  1:32     ` Chen, Tiejun
2014-09-11  7:52     ` Jan Beulich
2014-09-11 15:45   ` Jan Beulich
2014-09-12  4:52     ` Chen, Tiejun
2014-09-10  5:49 ` [v6][PATCH 6/7] hvmloader: check to reserved device memory maps in e820 Tiejun Chen
2014-09-11 15:57   ` Jan Beulich
2014-09-12  6:08     ` Jan Beulich
2014-09-12  6:28     ` Chen, Tiejun
2014-09-12  6:44       ` Jan Beulich
2014-09-10  5:49 ` [v6][PATCH 7/7] xen/vtd: make USB RMRR mapping safe Tiejun Chen
2014-09-18  9:11   ` Jan Beulich
2014-09-10 21:44 ` [v6][PATCH 0/7] xen: reserve RMRR to avoid conflicting MMIO/RAM Tian, Kevin
2014-09-11  1:38   ` Chen, Tiejun [this message]
2014-09-11  7:48     ` Jan Beulich
2014-09-11  9:39       ` Chen, Tiejun
2014-09-11 10:01         ` 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=5410FD10.1020603@intel.com \
    --to=tiejun.chen@intel.com \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yang.z.zhang@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 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.