Re: [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader

["Roger Pau Monné" <roger.pau@citrix.com>]

On Thu, Jun 02, 2016 at 12:37:27PM -0400, Boris Ostrovsky wrote:
> On 06/02/2016 08:40 AM, Jan Beulich wrote:
> >>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> >> This is an RFC for making hvmloader's ACPI builder available to both the
> >> toolstack and the hypervisor, as discussed in
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html 
> >>
> >> The series
> >> * Removes dependency of today's builder on hvmloader interfaces
> >> * Makes many of the tables built optionally.
> >> * Moves tools/hvmloader/acpi directory to xen/common/libacpi
> >> * Builds tables for PVHv2 domU guests in libxc
> >>
> >> There is still a number of questions about this implementation, thus it's
> >> an RFC. Examples of things that need to be discussed are
> >>
> >> * ACPI tables are built for PVHv2 guests unconditionally. We probably want
> >>   to make this an option.
> >> * Not sure about header files, especially xen/common/libacpi/x86.h and 
> >>   tools/firmware/hvmloader/{stdio.h,string.h} 
> >> * The builder is compiled into the hypervisor even though currently
> >>   there are no users (PVHv2 dom0 will be the one)
> > Is that really what we want? I thought we don't really mean to
> > build ACPI tables from scratch for Dom0, but rather follow ARM's
> > customization approach.
> 
> You mean xen/arch/arm/domain_build.c:prepare_acpi()?
> 
> The thinking was that customization will be able to make use of this
> library. Roger?

Yes, I (at least) thought that the same library would be used for crafting 
the tables for DomU or customizing the ones presented to Dom0 so that all 
the ACPI code resides at the same place. I was planning to place this code 
in the Xen .init section, so that it's gone after Dom0 construction.

Roger.

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