| Message ID | 20230317165440.24846-1-Jonathan.Cameron@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | hw/i386: Factor out PXB parts of DSDT into an SSDT table | expand |
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 >
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 > >
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 > > > >
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.
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)