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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

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
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