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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 07.07.16 at 17:12, <julien.grall@arm.com> wrote:

> 
> 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.

This is still RAM from a host resource accounting POV.

> 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.

For some parts iirc, and not for others. See also (for example) the
recent discussion George had with PGNet Dev
(https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00353.html).

Jan


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