Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 06/01/2016 09:21 AM, Julien Grall wrote:
>
>
> On 01/06/16 13:59, Boris Ostrovsky wrote:
>> On 06/01/2016 08:42 AM, Julien Grall wrote:
>>> On 31/05/16 21:51, Boris Ostrovsky wrote:
>>>> On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote:
>>>>> On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote:
>>>>>> From: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
>>>>>>
>>>>>> The design of this feature is described as below.
>>>>>> Firstly, the toolstack (libxl) generates the ACPI tables
>>>>>> according the
>>>>>> number of vcpus and gic controller.
>>>>> CC-ing Boris - who has been working on exposing ACPI tables
>>>>> for PVH guests.
>>>>>
>>>>> Is there some way of re-using some of the code?
>>>>
>>>> Indeed it would be good to keep all ACPI code in single place.
>>>>
>>>> I sent a patch series a while ago
>>>> (http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00625.html)
>>>>
>>>>
>>>> but because of release work it hasn't been reviewed yet. Shannon, can
>>>> you take a look at it and see whether you code can make use of what is
>>>> proposed there? It builds all the tables that you are building here
>>>> except for GTDT and provides libxc interface.
>>>
>>> AFAICT, your library is creating ACPI 1.0/2.0 tables. However the
>>> support for ARM has been added in ACPI 5.1.
>>>
>>> Looking at the list of tables built by the library, we might be able
>>> to re-use the code for SRAT, SLIT, FADT, RSDP. The rest is x86
>>> specific (WAET, MADT, HPET, SSDT_{PM,S3,S4}, TCPA (?)).
>>
>> The interface allows choosing which tables to generate so that shouldn't
>> be a problem.
>
> Would it be possible to opt-out some of the tables at built-time.
> Maybe by moving the code in separate files?

You mean per-arch (like what you are saying below)? Sure, if we can
identify which tables the we can split them into separate files.

-boris

>
>>>
>>> In the current state, I think the benefits for ARM is very limited. I
>>> agree that having a common library to manipulate ACPI would be nice,
>>> however, this would need a better abstraction to support different
>>> version and avoid to build unnecessary code.
>>>
>>
>> Can you suggest improvements to that series so that (even if not now but
>> at some point later) it is easier to integrate ARM and x86? Again, this
>> code is an RFC so now is the time to do it right.
>
> I agree :). I think the 2 points that would make easier to integrate
> ARM are:
>    - Newer version of ACPI (I know that you need to keep ACPI 1.0/2.0
> for some old guests).
>    - Possibility to have per-arch tables and fields. For instance the
> MADT will be different for ARM. Also, some fields in the FADT are ARM
> specific (see arm_boot_flags).
>
> I have not yet review this series, so it is my best guess. Shannon,
> any opinions?
>
> Regards,
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel