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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.06.16 at 09:18, <roger.pau@xxxxxxxxxx> wrote:
> 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@xxxxxxxxxx> 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.

Okay, I can't see much code sharing between customization and
creation from scratch, but I can certainly be convinced otherwise.

> I was planning to place this code 
> in the Xen .init section, so that it's gone after Dom0 construction.

Sure, that's a requirement in any case (just like is the case for libelf).

Jan


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