Re: [Xen-devel] HVM support for e820_host (Was: Bug: Limitation of <=2GB RAM in domU persists with 4.3.0)

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

Gordan Bobic <gordan@xxxxxxxxxx> wrote:
>On 09/05/2013 11:23 PM, Konrad Rzeszutek Wilk wrote:
>> Gordan Bobic <gordan@xxxxxxxxxx> wrote:
>>> Right, finally got around to trying this with the latest patch.
>>>
>>> With e820_host=0 things work as before:
>>>
>>> (XEN) HVM3: BIOS map:
>>> (XEN) HVM3:  f0000-fffff: Main BIOS
>>> (XEN) HVM3: E820 table:
>>> (XEN) HVM3:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
>>> (XEN) HVM3:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
>>> (XEN) HVM3:  HOLE: 00000000:000a0000 - 00000000:000e0000
>>> (XEN) HVM3:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
>>> (XEN) HVM3:  [03]: 00000000:00100000 - 00000000:e0000000: RAM
>>> (XEN) HVM3:  HOLE: 00000000:e0000000 - 00000000:fc000000
>>> (XEN) HVM3:  [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>> (XEN) HVM3:  [05]: 00000001:00000000 - 00000002:1f800000: RAM
>>>
>>>
>>> I seem to be getting two different E820 table dumps with
>e820_host=1:
>>>
>>> (XEN) HVM1: BIOS map:
>>> (XEN) HVM1:  f0000-fffff: Main BIOS
>>> (XEN) HVM1: build_e820_table:91 got 8 op.nr_entries
>>> (XEN) HVM1: E820 table:
>>> (XEN) HVM1:  [00]: 00000000:00000000 - 00000000:3f790000: RAM
>>> (XEN) HVM1:  [01]: 00000000:3f790000 - 00000000:3f79e000: ACPI
>>> (XEN) HVM1:  [02]: 00000000:3f79e000 - 00000000:3f7d0000: NVS
>>> (XEN) HVM1:  [03]: 00000000:3f7d0000 - 00000000:3f7e0000: RESERVED
>>> (XEN) HVM1:  HOLE: 00000000:3f7e0000 - 00000000:3f7e7000
>>> (XEN) HVM1:  [04]: 00000000:3f7e7000 - 00000000:40000000: RESERVED
>>> (XEN) HVM1:  HOLE: 00000000:40000000 - 00000000:fee00000
>>> (XEN) HVM1:  [05]: 00000000:fee00000 - 00000000:fee01000: RESERVED
>>> (XEN) HVM1:  HOLE: 00000000:fee01000 - 00000000:ffc00000
>>> (XEN) HVM1:  [06]: 00000000:ffc00000 - 00000001:00000000: RESERVED
>>> (XEN) HVM1:  [07]: 00000001:00000000 - 00000001:68870000: RAM
>>> (XEN) HVM1: E820 table:
>>> (XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
>>> (XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
>>> (XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
>>> (XEN) HVM1:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
>>> (XEN) HVM1:  [03]: 00000000:00100000 - 00000000:a7800000: RAM
>>> (XEN) HVM1:  HOLE: 00000000:a7800000 - 00000000:fc000000
>>> (XEN) HVM1:  [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
>>> (XEN) HVM1: Invoking ROMBIOS ...
>>>
>>> I cannot quite figure out what is going on here - these tables can't
>>> both be true.
>>>
>>
>> Right.  The code just prints the E820 that was constructed b/c of the
>e820_host =1 parameter as the first output.  Then the second one is
>what was constructed originally.
>>
>> The code that would tie in the E820 from the hyper call and the alter
>how the hvmloader sets it up is not yet done.
>>
>>
>>> Looking at the IOMEM on the host, the IOMEM begins at 0xa8000000 and
>>> goes more or less contiguously up to 0xfec8b000.
>>>
>>> Looking at dmesg on domU, the e820 map more or less matches the
>second
>>> dump above.
>>
>> Right.  That is correct since the patch I sent just outputs stuff. 
>No real changes to the E820 yet.
>
>I thought this did that in hvmloader/e820c:
>hypercall_memory_op ( XENMEM_memory_map, &op);
>
>Gordan

No.  They just gets the E820 that is stashed in the hypervisor for the guest.  
The PV guest would use it but hvmloader is not. This is what would needed to be 
implemented to allow hvmloader construct  the E820 on its own. 

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