[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 07/06/16 12:59, Shannon Zhao wrote:
On 2016/6/7 19:42, Julien Grall wrote:
On 07/06/16 12:35, Shannon Zhao wrote:
On 2016/6/7 19:27, Julien Grall wrote:
On 07/06/16 12:13, Shannon Zhao wrote:
On 2016/6/7 19:05, Julien Grall wrote:
Hello Shannon,
On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
---
tools/libxc/include/xc_dom.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h
b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
xen_pfn_t count;
};
+struct acpitable {
+ void *table;
+ size_t size;
+};
+
+struct acpitable_blob {
+ struct acpitable rsdp;
+ struct acpitable xsdt;
+ struct acpitable gtdt;
+ struct acpitable madt;
+ struct acpitable fadt;
+ struct acpitable dsdt;
+};
Is there any particular reason to expose the list of the tables
outside
of the building code?
I would provide a single buffer with all the tables inside. Similar to
what you did for building the tables in the hypervisor.
When it loads these tables to guest memory space, it needs to update
the
entries (pointing to other tables) of XSDT and also the
xsdt_physical_address in RSDP.
Why can't we load the ACPI tables at an hardcoded place in the memory
(for instance always at the beginning of the RAM)?
I think it's more reasonable to let the codes dynamically compute where
it should put these tables at like what it does for the devicetree blob.
And to an hardcoded place, can you make sure that kind of place is
always available and not used by others?
Yes, the toolstack is in charge of the memory layout. So it can ensure
that no-one else is using this region.
My concern is, based on you patch #13, the ACPI tables are allocated
just after all the other modules. However, they cannot be relocated by
the kernel because they contain physical address. So they have to stay
in place for all the life of the domain.
No, this doesn't like what you say. UEFI will install and relocate the
ACPI tables again for guest kernel. That means the ACPI tables guest
gets are not from the original place where toolstack puts them at.
Why does UEFI need to relocate the ACPI tables?
Anyway, you rely on the UEFI firmware to always relocating the tables.
What would happen if they decide to remove this behavior?
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
