[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 07/07/2016 04:38 AM, Jan Beulich wrote:
>>>> On 06.07.16 at 19:33, <boris.ostrovsky@xxxxxxxxxx> 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.

-boris



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.