[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/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@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.
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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
