xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	yang.z.zhang@intel.com
Subject: Re: [RFC][PATCH 4/5] tools:firmware:hvmloader: reserve RMRR mappings in e820
Date: Fri, 08 Aug 2014 10:01:03 +0100	[thread overview]
Message-ID: <53E4ADEF020000780002A7C0@mail.emea.novell.com> (raw)
In-Reply-To: <53E48CB6.1090303@intel.com>

>>> On 08.08.14 at 10:39, <tiejun.chen@intel.com> wrote:
> On 2014/8/8 15:43, Jan Beulich wrote:
>> More reasonable, albeit now you lost the fetch-just-once behavior.
>> Furthermore - do you really need this to be a dynamic allocation?
> 
> So,
> 
> diff --git a/tools/firmware/hvmloader/util.c 
> b/tools/firmware/hvmloader/util.c
> index 80d822f..d55773e 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -766,6 +766,17 @@ struct shared_info *get_shared_info(void)
>       return shared_info;
>   }
> 
> +struct e820map *get_rmrr_map_info(void)
> +{
> +    if ( rmrr_e820map.nr_map )
> +        return &rmrr_e820map;
> +
> +    if ( hypercall_memory_op(XENMEM_RMRR_memory_map, &rmrr_e820map) != 0 )
> +        BUG();
> +
> +    return &rmrr_e820map;
> +}

Still not quite, since now you still re-invoke the hypercall if the first
one didn't return any entries (e.g. on a VT-d-less system).

> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -236,6 +236,8 @@ unsigned long create_pir_tables(void);
>   void smp_initialise(void);
> 
>   #include "e820.h"
> +struct e820map rmrr_e820map;
> +struct e820map *get_rmrr_map_info(void);
>   int build_e820_table(struct e820entry *e820,
>                        unsigned int lowmem_reserved_base,
>                        unsigned int bios_image_base);
> 
> 
>> The structure you use right now is fixed size. Which gets me to
>> another point though: Is it said in any part of the VT-d spec that
>> there is an upper limit to the number of RMRRs? The re-use of the
> 
> After look up some relevant info in VT-D specs, I think we have no any 
> direct field to limit the number of RMRRs. Just in 8.1 DMA Remapping 
> Reporting Structure, there are some fields to be referred here:
> 
> #1 Length:
> 
> in bytes, of the description table including the length of the 
> associated remapping structures.
> 
> #2 Remapping Structures[]:
> 
> A list of structures. The list will contain one or more DMA Remapping 
> Hardware Unit Definition (DRHD) structures, and zero or more Reserved 
> Memory Region Reporting (RMRR) and Root Port ATS Capability Reporting 
> (ATSR) structures.
> 
> Seems no any explicit restriction.

IOW a fixed-length interface structure isn't a proper fit here.

Jan

  reply	other threads:[~2014-08-08  9:01 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-07 11:02 [RFC][PATCH 0/5] xen: reserve RMRR to avoid conflicting MMIO/RAM Tiejun Chen
2014-08-07 11:02 ` [RFC][PATCH 1/5] xen:x86: record RMRR mappings Tiejun Chen
2014-08-08 15:36   ` Jan Beulich
2014-08-11  3:04     ` Chen, Tiejun
2014-08-11  6:51       ` Jan Beulich
2014-08-11  7:00         ` Chen, Tiejun
2014-08-11  8:42           ` Jan Beulich
2014-08-07 11:02 ` [RFC][PATCH 2/5] xen:x86: introduce a new hypercall to get " Tiejun Chen
2014-08-08 15:45   ` Jan Beulich
2014-08-12 10:55     ` Chen, Tiejun
2014-08-12 12:19       ` Jan Beulich
2014-08-13  0:40         ` Chen, Tiejun
2014-08-13 18:21           ` Tian, Kevin
2014-08-14  1:07             ` Chen, Tiejun
2014-08-14 16:51               ` Jan Beulich
2014-08-15  6:13                 ` Chen, Tiejun
2014-08-07 11:02 ` [RFC][PATCH 3/5] tools:libxc: remove mmio BAR out of " Tiejun Chen
2014-08-08 15:49   ` Jan Beulich
2014-08-08 21:33     ` Tian, Kevin
2014-08-12 10:56       ` Chen, Tiejun
2014-08-12 12:21         ` Jan Beulich
2014-08-12 10:55     ` Chen, Tiejun
2014-08-07 11:02 ` [RFC][PATCH 4/5] tools:firmware:hvmloader: reserve RMRR mappings in e820 Tiejun Chen
2014-08-07 12:03   ` Andrew Cooper
2014-08-08  2:11     ` Chen, Tiejun
2014-08-08  6:42       ` Jan Beulich
2014-08-08  7:30         ` Chen, Tiejun
2014-08-08  7:43           ` Jan Beulich
2014-08-08  8:39             ` Chen, Tiejun
2014-08-08  9:01               ` Jan Beulich [this message]
2014-08-08  9:28                 ` Chen, Tiejun
2014-08-08 15:53   ` Jan Beulich
2014-08-08 15:58     ` Andrew Cooper
2014-08-11  6:48       ` Jan Beulich
2014-08-12  7:59     ` Chen, Tiejun
2014-08-08 21:47   ` Tian, Kevin
2014-08-11  6:53     ` Jan Beulich
2014-08-11 16:00       ` Tian, Kevin
2014-08-12 10:59         ` Chen, Tiejun
2014-08-12 12:25           ` Jan Beulich
2014-08-13  0:57             ` Chen, Tiejun
2014-08-13 19:10               ` Tian, Kevin
2014-08-14  3:03                 ` Chen, Tiejun
2014-08-14 23:11                   ` Tian, Kevin
2014-08-15  8:21                     ` Chen, Tiejun
2014-08-12 10:56       ` Chen, Tiejun
2014-08-12 12:22         ` Jan Beulich
2014-08-12 10:56     ` Chen, Tiejun
2014-08-07 11:02 ` [RFC][PATCH 5/5] 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=53E4ADEF020000780002A7C0@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.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).