[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

 


Rackspace

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