Re: [Xen-devel] [RFC][PATCH 1/5] xen:x86: record RMRR mappings

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

On 2014/8/11 14:51, Jan Beulich wrote:
> > > > On 11.08.14 at 05:04, <tiejun.chen@xxxxxxxxx> wrote:
> > On 2014/8/8 23:36, Jan Beulich wrote:
> > > > > > On 07.08.14 at 13:02, <tiejun.chen@xxxxxxxxx> wrote:
> > > > +/* Record RMRR mapping to ready expose VM. */
> > > > +static int __init rmrr_e820_register(struct acpi_rmrr_unit *rmrr)
> > > > +{
> > > > +    static int i = 0;
> > > > +
> > > > +    rmrr_e820.map[i].addr = rmrr->base_address;
> > > > +    rmrr_e820.map[i].size = rmrr->end_address - rmrr->base_address;
> > > > +    rmrr_e820.map[i].type = E820_RESERVED;
> > > > +    rmrr_e820.nr_map = i;
> > > > +    i++;
> > > > +    return 0;
> > > > +}
> > > As already said elsewhere, the piggybacking on the E820 structure
> > > isn't suitable here due to that ones limited size.
> > Are you saying the limited number of e820entry? If yes, I don't think
> > this would be limited here.
> >
> > Because struct e820map always define this as follows,
> >
> > #define E820MAX 128
> >
> > struct e820map {
> >       unsigned int nr_map;
> >       struct e820entry map[E820MAX];
> > };
> So are you saying that to you 128 is not a limit?
When we post that hypercall initially, we don't set up the limitation 
but Xen should reset the nr_map to indicate the real number.
> Btw., along with re-doing all this, I'd also strongly suggest not making
> the new hypercall a mem-op - this is clearly more like a sysctl or
Without hypercall how to build guest e820 table by the hvmloader? Or you 
mean we can set these rmrr info into build_info_table or elsewhere 
hvmloader can get them directly?
Thanks
Tiejun

> platform-op (but the latter might be too restrictive in terms of who
> may call it).
>
> Jan
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel