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

[Julien Grall <julien.grall@xxxxxxx>]

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.
Cheers,

--
Julien Grall

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