[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT t
From: |
Michael S. Tsirkin |
Subject: |
Re: [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table |
Date: |
Fri, 7 Apr 2023 03:37:00 -0400 |
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
> >