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

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

On 2014/8/11 14:51, Jan Beulich wrote:
>>>> On 11.08.14 at 05:04, <tiejun.chen@intel.com> wrote:
>> On 2014/8/8 23:36, Jan Beulich wrote:
>>>>>> On 07.08.14 at 13:02, <tiejun.chen@intel.com> 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
>
>