Re: [RFC][v3][PATCH 1/6] xen:x86: record RMRR mappings

["Jan Beulich" <JBeulich@suse.com>]

>>> On 15.08.14 at 11:39, <andrew.cooper3@citrix.com> wrote:
>> @@ -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
> than 128 times, or you need to do dynamic allocation of the storage.

This together with ...

>> --- a/xen/include/asm-x86/e820.h
>> +++ b/xen/include/asm-x86/e820.h
>> @@ -23,6 +23,8 @@ struct e820map {
>>      struct e820entry map[E820MAX];
>>  };
>>  
>> +typedef struct e820map rmrr_maps_t;
> 
> This type is a single map of RMRR regions, not multiple maps. 
> rmrr_map_t please.

... this once again stresses what I stated previously: Piggybacking
on the E820 handling here is just the wrong approach. There's
really no correlation with E820 other than us wanting to use the
gathered information for (among other things) adjusting the guest
E820 table. But that doesn't in any way require any re-use of
non-suitable data structures.

In fact I don't see the need for this first patch anyway, as RMRRs
are already being put on a linked list as they get found. I.e. the
patch here just clones existing information.

Jan