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

[Julien Grall <julien.grall@xxxxxxx>]

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?
> > 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel