Re: [Xen-devel] [V10 PATCH 0/4] pvh dom0 patches...

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On 02/05/14 17:41, Jan Beulich wrote:
>>>> On 02.05.14 at 16:35, <roger.pau@xxxxxxxxxx> wrote:
>> On 02/05/14 16:16, Jan Beulich wrote:
>>>>>> On 02.05.14 at 16:06, <roger.pau@xxxxxxxxxx> wrote:
>>>> My bad, I've incorrectly printed this as 0x%lu instead of %lx, the
>>>> following output is correct:
>>>>
>>>> SMAP type=01 base=0000000000000000 len=0000000000092400
>>>> SMAP type=02 base=00000000000f0000 len=0000000000010000
>>>> SMAP type=01 base=0000000000100000 len=000000003ff6e000
>>>> SMAP type=04 base=00000000dfdf9c00 len=0000000000052000
>>>> SMAP type=03 base=00000000dfe4bc00 len=0000000000002000
>>>> SMAP type=02 base=00000000dfe4dc00 len=00000000001b2400
>>>> SMAP type=02 base=00000000f8000000 len=0000000005000000
>>>> SMAP type=02 base=00000000fe000000 len=0000000000d00400
>>>> SMAP type=02 base=00000000fee00000 len=0000000000100000
>>>> SMAP type=02 base=00000000ffb00000 len=0000000000500000
>>>> SMAP type=02 base=0000000100000000 len=00000000a0000000
> 
> Considering the hypervisor view below, this range clearly is then
> wrong here too, ...
> 
>> Maybe the problem is on FreeBSD, and I'm not correctly clamping the e820
>> memory map returned by Xen. Right now I'm using start_info->nr_pages as
>> the number of valid RAM pages assigned to Dom0, but it is not clear if
>> start_info->nr_pages also takes into account the holes and invalid
>> regions in the e820 memory map.
> 
> i.e. yes, there must be some kind of problem in your handling in any
> case.
> 
>> This is the hw memory map reported by Xen:
>>
>> (XEN) Xen-e820 RAM map:
>> (XEN)  0000000000000000 - 0000000000092400 (usable)
>> (XEN)  00000000000f0000 - 0000000000100000 (reserved)
>> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
>> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
>> (XEN)  00000000dfe4bc00 - 00000000dfe4dc00 (ACPI data)
>> (XEN)  00000000dfe4dc00 - 00000000e0000000 (reserved)
>> (XEN)  00000000f8000000 - 00000000fd000000 (reserved)
>> (XEN)  00000000fe000000 - 00000000fed00400 (reserved)
>> (XEN)  00000000fee00000 - 00000000fef00000 (reserved)
>> (XEN)  00000000ffb00000 - 0000000100000000 (reserved)
>> (XEN)  0000000100000000 - 00000001a0000000 (usable)
>>
>> And the Dom0 is assigned 1024M of RAM.
> 
> I.e. it can have pages at or beyond 0x40000000 only if some other
> region is unpopulated.

If I got this right, it means that the maximum populated gpfn on the
domain is (start_info->nr_pages << PAGE_SHIFT), which is kind of odd,
because on PVH Dom0 all the holes in the memory map are already set to
p2m_mmio_direct (see pvh_map_all_iomem in patch 1), so I don't think
there's anything I can unpopulate, and it means that the dom0_mem param
passed in the command line is not properly handled, because the actual
usable RAM assigned to the Dom0 will vary depending on the underlying
hardware e820 map.

Roger.

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