Re: [Xen-devel] [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.06.16 at 16:47, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 06/07/2016 10:10 AM, Jan Beulich wrote:
>>>>> On 07.06.16 at 15:59, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 06/07/2016 02:17 AM, Jan Beulich wrote:
>>>>>>> On 06.06.16 at 18:59, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>> On 06/06/2016 09:29 AM, Jan Beulich wrote:
>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>> RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka 
>>>>> ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need 
>>>>> SystemMemory so it can be anywhere (and e820 should presumably be aware 
>>>>> of 
>>>>> this, which it is not right now)
>>>> So you say there's no connection to the end of hvmloader's window
>>>> for PCI MMIO assignments (an equivalent of which is going to be
>>>> needed for PVHv2)?
>>> I haven't thought about this but then we don't have MMIO hole now. I can
>>> try finding available memory chunk in guest's memory under 4G.
>> Well, we first need to settle on the intended memory layout.
>> And then we need to put this down in exactly one place, for all
>> players to consume (and adhere to).
> 
> On the few systems that I looked at they are placed right before the
> MMIO region.
> 
> How about (HVM_BELOW_4G_RAM_END - NUM_ACPI_PAGES)?

Sounds reasonable. But as said - all involved parties need to be
made agree on memory use.

Jan


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