[RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table

Jonathan Cameron via posted 4 patches 1 year ago
hw/acpi/aml-build.c           |  75 +++++-----
hw/i386/acpi-build.c          | 249 ++++++++++++++++++++++------------
hw/pci-host/gpex-acpi.c       |   5 +-
include/hw/acpi/aml-build.h   |   4 +-
tests/data/acpi/q35/DSDT.cxl  | Bin 9673 -> 8474 bytes
tests/data/acpi/q35/DSDT.viot | Bin 9470 -> 8429 bytes
tests/data/acpi/q35/SSDT.cxl  | Bin 0 -> 1235 bytes
tests/data/acpi/q35/SSDT.viot | Bin 0 -> 1077 bytes
8 files changed, 208 insertions(+), 125 deletions(-)
create mode 100644 tests/data/acpi/q35/SSDT.cxl
create mode 100644 tests/data/acpi/q35/SSDT.viot
[RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table
Posted by Jonathan Cameron via 1 year ago
Michael Tsirkin raised that we have recently had churn in the bios-tables-test
and perhaps it was worth factoring some parts of DSDT out as SSDT files.
This is an attempt to do that for the entries from pxb-pcie and pxb-cxl
PCI root bridges.

The main PCI root bridge and related elements are left in DSDT as they
are present in many more tests than PXB.  However things brings some
complexity as some of the DSDT parts are then dependent on building up
information whilst creating the PXB entries.  The ordering constraints
of RSDT entries prevent easily generating the new SSDT table first
(see patch 3)

This series works around that by separating that build up of information from
the build up of the PXB parts of the SSDT.  That allows the tables to be
build in the standard order, based on knowledge that the SSDT parts will
definitely be built later.

Personally, having tried this, I'm not convinced that the advantages of
simplifying updates to the test data justify the complexity increase needed.
However I will add that I have a series adding CXL QTG DSM support form Dave
Jiang in my tree that will only result in updates to SSDT.cxl after this patch
rather than DSDT.cxl reducing chance of a clash with other changes
in flight. Hence this is an RFC to find out if people think this is
a good direction to go in.

Suggested-by: Michael S. Tsirkin <mst@redhat.com>
https://lore.kernel.org/qemu-devel/20230302055544-mutt-send-email-mst@kernel.org/	


Jonathan Cameron (4):
  hw/acpi: Make Aml and / or crs_range_set optional in build_crs
  tests/acpi: Allow changes to DSDT.cxl/viot and SSDT.cxl/viot
  hw/i386/acpi: Separate PXB related parts of DSDT into an SSDT table.
  tests/acpi: Updated DSDT and SSDT due to move of PXB info to SSDT

 hw/acpi/aml-build.c           |  75 +++++-----
 hw/i386/acpi-build.c          | 249 ++++++++++++++++++++++------------
 hw/pci-host/gpex-acpi.c       |   5 +-
 include/hw/acpi/aml-build.h   |   4 +-
 tests/data/acpi/q35/DSDT.cxl  | Bin 9673 -> 8474 bytes
 tests/data/acpi/q35/DSDT.viot | Bin 9470 -> 8429 bytes
 tests/data/acpi/q35/SSDT.cxl  | Bin 0 -> 1235 bytes
 tests/data/acpi/q35/SSDT.viot | Bin 0 -> 1077 bytes
 8 files changed, 208 insertions(+), 125 deletions(-)
 create mode 100644 tests/data/acpi/q35/SSDT.cxl
 create mode 100644 tests/data/acpi/q35/SSDT.viot

-- 
2.37.2
Re: [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table
Posted by Jonathan Cameron via 11 months, 3 weeks ago
On Fri, 17 Mar 2023 16:54:36 +0000
Jonathan Cameron via <qemu-devel@nongnu.org> wrote:

> Michael Tsirkin raised that we have recently had churn in the bios-tables-test
> and perhaps it was worth factoring some parts of DSDT out as SSDT files.
> This is an attempt to do that for the entries from pxb-pcie and pxb-cxl
> PCI root bridges.
> 
> The main PCI root bridge and related elements are left in DSDT as they
> are present in many more tests than PXB.  However things brings some
> complexity as some of the DSDT parts are then dependent on building up
> information whilst creating the PXB entries.  The ordering constraints
> of RSDT entries prevent easily generating the new SSDT table first
> (see patch 3)
> 
> This series works around that by separating that build up of information from
> the build up of the PXB parts of the SSDT.  That allows the tables to be
> build in the standard order, based on knowledge that the SSDT parts will
> definitely be built later.
> 
> Personally, having tried this, I'm not convinced that the advantages of
> simplifying updates to the test data justify the complexity increase needed.
> However I will add that I have a series adding CXL QTG DSM support form Dave
> Jiang in my tree that will only result in updates to SSDT.cxl after this patch
> rather than DSDT.cxl reducing chance of a clash with other changes
> in flight. Hence this is an RFC to find out if people think this is
> a good direction to go in.
> 
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> https://lore.kernel.org/qemu-devel/20230302055544-mutt-send-email-mst@kernel.

Michael / all, at first glance at least, is sensible to take forwards?

Whilst I'm not in a rush on this, I'm carrying a bunch of patches
for next cycle that are on top of this at the moment, so I'm just wondering
whether it makes sense reorder things based on what might land first
/ not land at all.

Thanks,

Jonathan

> 
> 
> Jonathan Cameron (4):
>   hw/acpi: Make Aml and / or crs_range_set optional in build_crs
>   tests/acpi: Allow changes to DSDT.cxl/viot and SSDT.cxl/viot
>   hw/i386/acpi: Separate PXB related parts of DSDT into an SSDT table.
>   tests/acpi: Updated DSDT and SSDT due to move of PXB info to SSDT
> 
>  hw/acpi/aml-build.c           |  75 +++++-----
>  hw/i386/acpi-build.c          | 249 ++++++++++++++++++++++------------
>  hw/pci-host/gpex-acpi.c       |   5 +-
>  include/hw/acpi/aml-build.h   |   4 +-
>  tests/data/acpi/q35/DSDT.cxl  | Bin 9673 -> 8474 bytes
>  tests/data/acpi/q35/DSDT.viot | Bin 9470 -> 8429 bytes
>  tests/data/acpi/q35/SSDT.cxl  | Bin 0 -> 1235 bytes
>  tests/data/acpi/q35/SSDT.viot | Bin 0 -> 1077 bytes
>  8 files changed, 208 insertions(+), 125 deletions(-)
>  create mode 100644 tests/data/acpi/q35/SSDT.cxl
>  create mode 100644 tests/data/acpi/q35/SSDT.viot
>
Re: [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table
Posted by Michael S. Tsirkin 11 months, 3 weeks ago
On Thu, Apr 06, 2023 at 11:25:47AM +0100, Jonathan Cameron wrote:
> On Fri, 17 Mar 2023 16:54:36 +0000
> Jonathan Cameron via <qemu-devel@nongnu.org> wrote:
> 
> > Michael Tsirkin raised that we have recently had churn in the bios-tables-test
> > and perhaps it was worth factoring some parts of DSDT out as SSDT files.
> > This is an attempt to do that for the entries from pxb-pcie and pxb-cxl
> > PCI root bridges.
> > 
> > The main PCI root bridge and related elements are left in DSDT as they
> > are present in many more tests than PXB.  However things brings some
> > complexity as some of the DSDT parts are then dependent on building up
> > information whilst creating the PXB entries.  The ordering constraints
> > of RSDT entries prevent easily generating the new SSDT table first
> > (see patch 3)
> > 
> > This series works around that by separating that build up of information from
> > the build up of the PXB parts of the SSDT.  That allows the tables to be
> > build in the standard order, based on knowledge that the SSDT parts will
> > definitely be built later.
> > 
> > Personally, having tried this, I'm not convinced that the advantages of
> > simplifying updates to the test data justify the complexity increase needed.
> > However I will add that I have a series adding CXL QTG DSM support form Dave
> > Jiang in my tree that will only result in updates to SSDT.cxl after this patch
> > rather than DSDT.cxl reducing chance of a clash with other changes
> > in flight. Hence this is an RFC to find out if people think this is
> > a good direction to go in.
> > 
> > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > https://lore.kernel.org/qemu-devel/20230302055544-mutt-send-email-mst@kernel.
> 
> Michael / all, at first glance at least, is sensible to take forwards?
> 
> Whilst I'm not in a rush on this, I'm carrying a bunch of patches
> for next cycle that are on top of this at the moment, so I'm just wondering
> whether it makes sense reorder things based on what might land first
> / not land at all.
> 
> Thanks,
> 
> Jonathan

Yes, I like this. Igor had some reservations about the split-up. Igor
can you comment please?


> > 
> > 
> > Jonathan Cameron (4):
> >   hw/acpi: Make Aml and / or crs_range_set optional in build_crs
> >   tests/acpi: Allow changes to DSDT.cxl/viot and SSDT.cxl/viot
> >   hw/i386/acpi: Separate PXB related parts of DSDT into an SSDT table.
> >   tests/acpi: Updated DSDT and SSDT due to move of PXB info to SSDT
> > 
> >  hw/acpi/aml-build.c           |  75 +++++-----
> >  hw/i386/acpi-build.c          | 249 ++++++++++++++++++++++------------
> >  hw/pci-host/gpex-acpi.c       |   5 +-
> >  include/hw/acpi/aml-build.h   |   4 +-
> >  tests/data/acpi/q35/DSDT.cxl  | Bin 9673 -> 8474 bytes
> >  tests/data/acpi/q35/DSDT.viot | Bin 9470 -> 8429 bytes
> >  tests/data/acpi/q35/SSDT.cxl  | Bin 0 -> 1235 bytes
> >  tests/data/acpi/q35/SSDT.viot | Bin 0 -> 1077 bytes
> >  8 files changed, 208 insertions(+), 125 deletions(-)
> >  create mode 100644 tests/data/acpi/q35/SSDT.cxl
> >  create mode 100644 tests/data/acpi/q35/SSDT.viot
> >
Re: [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table
Posted by Igor Mammedov 11 months, 3 weeks ago
On Fri, 7 Apr 2023 03:37:00 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, Apr 06, 2023 at 11:25:47AM +0100, Jonathan Cameron wrote:
> > On Fri, 17 Mar 2023 16:54:36 +0000
> > Jonathan Cameron via <qemu-devel@nongnu.org> wrote:
> >   
> > > Michael Tsirkin raised that we have recently had churn in the bios-tables-test
> > > and perhaps it was worth factoring some parts of DSDT out as SSDT files.
> > > This is an attempt to do that for the entries from pxb-pcie and pxb-cxl
> > > PCI root bridges.
> > > 
> > > The main PCI root bridge and related elements are left in DSDT as they
> > > are present in many more tests than PXB.  However things brings some
> > > complexity as some of the DSDT parts are then dependent on building up
> > > information whilst creating the PXB entries.  The ordering constraints
> > > of RSDT entries prevent easily generating the new SSDT table first
> > > (see patch 3)
> > > 
> > > This series works around that by separating that build up of information from
> > > the build up of the PXB parts of the SSDT.  That allows the tables to be
> > > build in the standard order, based on knowledge that the SSDT parts will
> > > definitely be built later.
> > > 
> > > Personally, having tried this, I'm not convinced that the advantages of
> > > simplifying updates to the test data justify the complexity increase needed.
> > > However I will add that I have a series adding CXL QTG DSM support form Dave
> > > Jiang in my tree that will only result in updates to SSDT.cxl after this patch
> > > rather than DSDT.cxl reducing chance of a clash with other changes
> > > in flight. Hence this is an RFC to find out if people think this is
> > > a good direction to go in.
> > > 
> > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > https://lore.kernel.org/qemu-devel/20230302055544-mutt-send-email-mst@kernel.  
> > 
> > Michael / all, at first glance at least, is sensible to take forwards?
> > 
> > Whilst I'm not in a rush on this, I'm carrying a bunch of patches
> > for next cycle that are on top of this at the moment, so I'm just wondering
> > whether it makes sense reorder things based on what might land first
> > / not land at all.
> > 
> > Thanks,
> > 
> > Jonathan  
> 
> Yes, I like this. Igor had some reservations about the split-up. Igor
> can you comment please?

Well, as Jonathan said, I'm also not convinced that it does more good
than getting code worse condition.
In this case my preference is to keep code simpler vs occasional merge
conflict/rebasing.

In virt world SSDTs don't make much sense as tables are build dynamically,
they just introducing more complexity (incl. less blobs to deal with in tests).
(that was one of the reasons we got rid of them practically as soon as
we had switched from patching prebuilt AML blobs to aml_foo() API).

PS:
wrt nvdimm ssdt, it was fairly isolated feature with lot of updates,
so it made some sense to have a dedicated table just to simplify
review/reduce merge conflicts.
(probably it was me who suggested to use separate table).
But in retrospective it wouldn't make much difference if it were in DSDT.
Perhaps we should merge nvdimm's SSDT back into DSDT as it is
more or less stable nowadays.

PS2:
Also, I'm working on expanding PCI slots descriptors to PXBs,
and more or less that will negate this tables split. 

> > > 
> > > 
> > > Jonathan Cameron (4):
> > >   hw/acpi: Make Aml and / or crs_range_set optional in build_crs
> > >   tests/acpi: Allow changes to DSDT.cxl/viot and SSDT.cxl/viot
> > >   hw/i386/acpi: Separate PXB related parts of DSDT into an SSDT table.
> > >   tests/acpi: Updated DSDT and SSDT due to move of PXB info to SSDT
> > > 
> > >  hw/acpi/aml-build.c           |  75 +++++-----
> > >  hw/i386/acpi-build.c          | 249 ++++++++++++++++++++++------------
> > >  hw/pci-host/gpex-acpi.c       |   5 +-
> > >  include/hw/acpi/aml-build.h   |   4 +-
> > >  tests/data/acpi/q35/DSDT.cxl  | Bin 9673 -> 8474 bytes
> > >  tests/data/acpi/q35/DSDT.viot | Bin 9470 -> 8429 bytes
> > >  tests/data/acpi/q35/SSDT.cxl  | Bin 0 -> 1235 bytes
> > >  tests/data/acpi/q35/SSDT.viot | Bin 0 -> 1077 bytes
> > >  8 files changed, 208 insertions(+), 125 deletions(-)
> > >  create mode 100644 tests/data/acpi/q35/SSDT.cxl
> > >  create mode 100644 tests/data/acpi/q35/SSDT.viot
> > >   
>
Re: [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table
Posted by Michael S. Tsirkin 11 months, 3 weeks ago
On Tue, Apr 11, 2023 at 04:02:19PM +0200, Igor Mammedov wrote:
> PS2:
> Also, I'm working on expanding PCI slots descriptors to PXBs,
> and more or less that will negate this tables split. 

Hmm any ETA?  We can defer this discussion until after that is posted.

-- 
MST
Re: [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table
Posted by Igor Mammedov 11 months, 3 weeks ago
On Tue, 11 Apr 2023 10:05:01 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Tue, Apr 11, 2023 at 04:02:19PM +0200, Igor Mammedov wrote:
> > PS2:
> > Also, I'm working on expanding PCI slots descriptors to PXBs,
> > and more or less that will negate this tables split.   
> 
> Hmm any ETA?  We can defer this discussion until after that is posted.
Hopefully for 8.1.

Goal is to make acpi-index work on PXBs as well
so regardless of where user attaches NIC, interface naming
would still be working as expected.
(i.e. I'm not targeting bringing ACPI hotplug there but that
might be included as a side-effect)