Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests

[Julien Grall <julien.grall@arm.com>]

On 07/07/16 16:08, Boris Ostrovsky wrote:
> On 07/07/2016 04:38 AM, Jan Beulich wrote:
>>>>> On 06.07.16 at 19:33, <boris.ostrovsky@oracle.com> wrote:
>>> On 07/06/2016 01:03 PM, Julien Grall wrote:
>>>>
>>>> On 06/07/16 17:30, Boris Ostrovsky wrote:
>>>>> On 07/06/2016 12:04 PM, Julien Grall wrote:
>>>>>> Hi Boris,
>>>>>>
>>>>>> On 06/07/16 16:50, Boris Ostrovsky wrote:
>>>>>>> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>>>>>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>>>>>>>> +                               xen_pfn_t *extents,
>>>>>>>>> +                               unsigned int num_pages,
>>>>>>>>> +                               struct acpi_ctxt *ctxt)
>>>>>>>>> +{
>>>>>>>>> +    int rc;
>>>>>>>>> +    xc_interface *xch = dom->xch;
>>>>>>>>> +    uint32_t domid = dom->guest_domid;
>>>>>>>>> +    unsigned long idx, first_high_idx = (1ull << (32 -
>>>>>>>>> ctxt->page_shift));
>>>>>>>>> +
>>>>>>>>> +    for (; num_pages; num_pages--, extents++) {
>>>>>>>>> +
>>>>>>>>> +        if (xc_domain_populate_physmap(xch, domid, 1, 0, 0,
>>>>>>>>> extents)
>>>>>>>>> == 1)
>>>>>>>> It looks like this is working because libxl is setting the maximum
>>>>>>>> size of the domain with some slack (1MB). You might get in trouble if
>>>>>>>> the slack is reduced or used by someone or the ACPI blob is
>>>>>>>> increasing.
>>>>>>>
>>>>>>> I saw your conversation about slack with Stefano and I am not sure I
>>>>>>> understood what it was about. If this was about padding guest's memory
>>>>>>> to be able to put there some additional data (such ACPI tables) then
>>>>>>> this is not my intention here: if I can't populate (because it is
>>>>>>> already populated, I guess) then I try to move memory around with code
>>>>>>> below. That's what mem_hole_populate_ram() does as well.
>>>>>> The maximum amount of memory that could be assigned to a domain is
>>>>>> fixed per-domain. This maximum amount does not take into account the
>>>>>> size of the ACPI blob. So you may end up to fail because all the
>>>>>> memory was assigned somewhere else.
>>>>> Why shouldn't max amount of guest's memory include ACPI tables? I think
>>>>> we should fail and not rely on this slack if no more memory is
>>>>> available.
>>>>>
>>>>> ...
>>>> Because, at least for ARM, the ACPI memory region is not part of the
>>>> "real" RAM. So this value is not taken into account into the current
>>>> max mem.
>>>
>>> Hmm.. I've always assumed it is part of memory but marked as a special
>>> type in e820 map on x86. Maybe Andrew or Jan can comment on this.
>> I guess you both mean the same - note how Julien says _"real" RAM_.
>> So from a hypervisor resource consumption view this ought to be
>> considered RAM; from a guest view it wouldn't be.
>
> In which case we shouldn't pad maxmem specified by guest's config file.
> Space to put ACPI tables must come from requested resources. If the
> tables don't fit then more memory should have been asked for.

Why? In the case of ARM, the ACPI tables lives outside the guest RAM in 
a special region. I would have expect to be the same in x86.

If so, I don't think this should be part of the maxmem requested by the 
user. IIRC, it is the same of the PCI ROM. The maxmem is incremented by 
the toolstack.

Regards,

-- 
Julien Grall

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