From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>,
JBeulich@suse.com, ian.jackson@eu.citrix.com,
stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
yang.z.zhang@intel.com, kevin.tian@intel.com
Cc: xen-devel@lists.xen.org
Subject: Re: [RFC][v3][PATCH 1/6] xen:x86: record RMRR mappings
Date: Mon, 18 Aug 2014 10:51:15 +0100 [thread overview]
Message-ID: <53F1CC93.4020205@citrix.com> (raw)
In-Reply-To: <53F1AF19.4080003@intel.com>
On 18/08/14 08:45, Chen, Tiejun wrote:
> On 2014/8/15 17:39, Andrew Cooper wrote:
>> On 15/08/14 09:27, Tiejun Chen wrote:
>>> We will expose RMRR mappings to VM so need to record all
>>> RMRR mappings firstly.
>>>
>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>> ---
>>> xen/arch/x86/e820.c | 2 ++
>>> xen/drivers/passthrough/vtd/dmar.c | 14 ++++++++++++++
>>> xen/include/asm-x86/e820.h | 3 +++
>>> 3 files changed, 19 insertions(+)
>>>
>>> diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
>>> index 55fe0d6..db44afd 100644
>>> --- a/xen/arch/x86/e820.c
>>> +++ b/xen/arch/x86/e820.c
>>> @@ -34,6 +34,8 @@ static bool_t __initdata e820_verbose;
>>> boolean_param("e820-verbose", e820_verbose);
>>>
>>> struct e820map e820;
>>> +/* Used to record RMRR mapping. */
>>> +rmrr_maps_t rmrr_maps;
>>>
>>> /*
>>> * This function checks if the entire range <start,end> is mapped
>>> with type.
>>> diff --git a/xen/drivers/passthrough/vtd/dmar.c
>>> b/xen/drivers/passthrough/vtd/dmar.c
>>> index 1152c3a..24321e3 100644
>>> --- a/xen/drivers/passthrough/vtd/dmar.c
>>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>>> @@ -29,6 +29,7 @@
>>> #include <xen/pci.h>
>>> #include <xen/pci_regs.h>
>>> #include <asm/string.h>
>>> +#include <asm/e820.h>
>>> #include "dmar.h"
>>> #include "iommu.h"
>>> #include "extern.h"
>>> @@ -80,6 +81,18 @@ static int __init acpi_register_rmrr_unit(struct
>>> acpi_rmrr_unit *rmrr)
>>> return 0;
>>> }
>>>
>>> +/* Record RMRR mapping to ready expose VM. */
>>> +static int __init rmrr_maps_register(struct acpi_rmrr_unit *rmrr)
>>> +{
>>
>> You absolutely need some protection against calling this function more
>
> Could you show this assumed scenario?
>
> IMO, this should never be happened since we always use a e820 table to
> cover RMRR range/entries.
There is, as far as I am aware, no upper bound to the number of RMRRs
reported by the firmware. rmrr_maps.map is an array of length E820_MAX,
or 128. If this function is called more than 128 times, you will start
clobbering Xen data.
But as Jan pointed out in the other fork of this thread, this entire
function is not needed, and can be removed.
~Andrew
next prev parent reply other threads:[~2014-08-18 9:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 8:27 [RFC][v3][PATCH 0/6] xen: reserve RMRR to avoid conflicting MMIO/RAM Tiejun Chen
2014-08-15 8:27 ` [RFC][v3][PATCH 1/6] xen:x86: record RMRR mappings Tiejun Chen
2014-08-15 9:39 ` Andrew Cooper
2014-08-15 16:29 ` Jan Beulich
2014-08-18 7:42 ` Chen, Tiejun
2014-08-18 9:57 ` Andrew Cooper
2014-08-18 10:05 ` Chen, Tiejun
2014-08-18 12:31 ` Jan Beulich
2014-08-19 2:14 ` Chen, Tiejun
2014-08-19 2:28 ` Chen, Tiejun
2014-08-19 13:12 ` Jan Beulich
2014-08-18 7:45 ` Chen, Tiejun
2014-08-18 9:51 ` Andrew Cooper [this message]
2014-08-18 10:01 ` Chen, Tiejun
2014-08-18 12:56 ` Jan Beulich
2014-08-15 8:27 ` [RFC][v3][PATCH 2/6] xen:x86: introduce a new hypercall to get " Tiejun Chen
2014-08-15 9:46 ` Andrew Cooper
2014-08-18 7:46 ` Chen, Tiejun
2014-08-15 8:27 ` [RFC][v3][PATCH 3/6] tools:firmware:hvmloader: reserve RMRR mappings in e820 Tiejun Chen
2014-08-15 9:58 ` Andrew Cooper
2014-08-18 7:51 ` Chen, Tiejun
2014-08-18 10:00 ` Andrew Cooper
2014-08-15 8:27 ` [RFC][v3][PATCH 4/6] xen:x86: add XENMEM_reserved_device_memory_map to expose RMRR Tiejun Chen
2014-08-15 12:15 ` Andrew Cooper
2014-08-18 8:00 ` Chen, Tiejun
2014-08-18 10:06 ` Andrew Cooper
2014-08-15 8:27 ` [RFC][v3][PATCH 5/6] tools:libxc: check if mmio BAR is out of RMRR mappings Tiejun Chen
2014-08-15 12:21 ` Andrew Cooper
2014-08-18 8:05 ` Chen, Tiejun
2014-08-15 8:27 ` [RFC][v3][PATCH 6/6] xen:vtd: make USB RMRR mapping safe Tiejun Chen
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=53F1CC93.4020205@citrix.com \
--to=andrew.cooper3@citrix.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=tiejun.chen@intel.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 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).