[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 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. > 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. -- Shannon _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |