[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 09/15/2016 09:48 AM, Julien Grall wrote:
> Hi Boris,
> On 15/09/2016 13:39, Boris Ostrovsky wrote:
>> 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.
> I agree that it is not nice, but it would help us to get this features
> (and the other ones that depend on it) in Xen 4.8. Otherwise we would
> have to wait another 6 months to get those features.

If Jan (who is/will be libacpi maintainer) agrees to this it can be
easily added.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.