[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 11.08.14 at 09:00, <tiejun.chen@xxxxxxxxx> wrote:
> 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?

I similarly (as above) don't really understand what you're trying
to ask/tell me, but at least I now realize that you need to do this
call _inside_ the guest, so it can't be a sysctl.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.