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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 09/15/2016 06:22 AM, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote:
>> Hi Wei,
>>
>> On 15/09/2016 11:18, Wei Liu wrote:
>>> On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote:
>>>> On 09/07/2016 02:59 PM, Boris Ostrovsky wrote:
>>>>> The goal here is to build ACPI tables for PVHv2/HVMlite guests while 
>>>>> reusing existing
>>>>> hvmloader's ACPI builder code. The builder is provided as a library in 
>>>>> tools/libacpi.
>>>>>
>>>>> This is version 3 of the series, see individual patches for changes. It 
>>>>> can
>>>>> be fetched from git://oss.oracle.com/git/bostrovs/xen.git:acpi_v3
>>>> Wei, Ian --- are there any comments from the toolstack perspective?
>>>>
>>>>> The series is probably still gated by lack of an ACK from Lenovo for the
>>>>> relicensing patch (included here as patch 1).
>>>>>
>>>> So I looked again at commit 801d469ad8b2b88f669326327df03d03200efbfb
>>>> (which is the patch from Lenovo) and it only does 2 things (assuming I
>>>> parsed ASL correctly):
>>>> * Adds _PIC method
>>>> * Controls and describes legacy PCI interrupt routing. This
>>>> functionality has actually been moved into mk_dsdt.c and so this ASL
>>>> code is now generated.
>>>>
>>>> Neither of these two things is used by libxl so technically we may not
>>>> need the ACK from Lenovo. OTOH, we may forget about this restriction in
>>>> the future and accidentally include those two later.
>>>>
>>> This is a risk I would rather not take. As you said, we may forget about
>>> the restriction in the future.
>> Does it mean this series may not be in Xen 4.8? If so, this will also delay
>> other series such as the ACPI guest support for ARM.
>>
> I would like to see this and the subsequent ARM series in 4.8 -- it is
> still possible we get an ack from Lenovo any time, but the issue is out
> of our control at the moment. It's just one unfortunate incident in open
> source software development. Sigh.

One option could be to provide a 'gpl_all' (or some such) target in
libacpi in addition to 'all' and that target will be careful about not
including these small un-ACKed portions of the code.

It will be ugly though.

-boris

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