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

From: Julien Grall <julien.grall@arm.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Shannon Zhao <zhaoshenglong@huawei.com>
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, peter.huangpeng@huawei.com,
	xen-devel@lists.xen.org, shannon.zhao@linaro.org,
	"Jan Beulich" <jbeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 00/14] Xen ARM DomU ACPI support
Date: Wed, 1 Jun 2016 14:21:51 +0100	[thread overview]
Message-ID: <574EE16F.2060006@arm.com> (raw)
In-Reply-To: <574EDC38.2010804@oracle.com>

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@linaro.org>
>>>>>
>>>>> 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?

>>
>> 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,

-- 
Julien Grall

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