Re: [Xen-devel] [RFC][PATCH 4/5] tools:firmware:hvmloader: reserve RMRR mappings in e820

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2014/8/8 23:53, Jan Beulich wrote:
> > > > On 07.08.14 at 13:02, <tiejun.chen@xxxxxxxxx> wrote:
> > We need to reserve all RMRR mappings in e820 to avoid any
> > potential guest memory conflict.
> >
> > Signed-off-by: Tiejun Chen <tiejun.chen@xxxxxxxxx>
> > ---
> >   tools/firmware/hvmloader/e820.c | 14 ++++++++++++++
> >   tools/firmware/hvmloader/e820.h |  6 ++++++
> >   tools/firmware/hvmloader/util.c | 13 +++++++++++++
> >   tools/firmware/hvmloader/util.h |  1 +
> >   4 files changed, 34 insertions(+)
> > @@ -124,6 +126,18 @@ int build_e820_table(struct e820entry *e820,
> >       e820[nr].type = E820_RAM;
> >       nr++;
> >
> > +    /* We'd better reserve RMRR mapping for each VM to avoid potential
> > +     * memory conflict.
> > +     */
> > +    e820_rmrr_map = get_rmrr_map_info();
> > +    for ( i = 0; i <= e820_rmrr_map->nr_map; i++ )
> > +    {
> > +        e820[nr].addr = e820_rmrr_map->map[i].addr;
> > +        e820[nr].size = e820_rmrr_map->map[i].size + 1;
> > +        e820[nr].type = E820_RESERVED;
> > +        nr++;
> > +    }
> You can't just put this in an arbitrary place, without caring for overlaps
> (and ordering perhaps - I don't recall offhand whether E820 is
> required to be sorted, or whether that's just common practice). In fact
> I'm not certain the code block following your insertion (interestingly
> another Intel special) doesn't violate this too.
I will add some codes to sort nice in next revision.

Thanks
Tiejun

> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel