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

["Michael S. Tsirkin" <mst@redhat.com>]

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
> >