[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 13:32, Shannon Zhao wrote:
On 2016/6/7 20:06, Julien Grall wrote:
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?
That's its own mechanism I think and UEFI wants all the memory maps
under its control. And it's same for QEMU(x86 and ARM) and also for Xen
on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
is used for x86 Xen DomU.
UEFI cannot control the memory map because it is not capable to know
what a region is used for (such as magic pages, grant table...).
In the case of domU for x86, the ACPI table are located in predefine
physical address by hvmloader. I really don't see any reason that would
prevent us to do the same on ARM.
If the UEFI firmware wants to relocate the tables, then fine. But we
should also think about any firmware which may not relocate the tables.
Anyway, you rely on the UEFI firmware to always relocating the tables.
What would happen if they decide to remove this behavior?
Eh, I don't believe this would happen.
You seem very optimistic. Xen does not rely on a specific UEFI
implementation nor how a guest will behave. We have to predict what
could happen and find the best way to do it.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
