qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Jonathan Cameron via <qemu-devel@nongnu.org>,
	ani@anisinha.ca, berrange@redhat.com, Fan Ni <fan.ni@samsung.com>,
	Dave Jiang <dave.jiang@intel.com>
Subject: Re: [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table
Date: Tue, 11 Apr 2023 16:02:19 +0200	[thread overview]
Message-ID: <20230411160219.64f0aa2f@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <20230407033509-mutt-send-email-mst@kernel.org>

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



  reply	other threads:[~2023-04-11 14:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 16:54 [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table Jonathan Cameron via
2023-03-17 16:54 ` [RFC PATCH 1/4] hw/acpi: Make Aml and / or crs_range_set optional in build_crs Jonathan Cameron via
2023-03-17 16:54 ` [RFC PATCH 2/4] tests/acpi: Allow changes to DSDT.cxl/viot and SSDT.cxl/viot Jonathan Cameron via
2023-03-17 16:54 ` [RFC PATCH 3/4] hw/i386/acpi: Separate PXB related parts of DSDT into an SSDT table Jonathan Cameron via
2023-03-17 16:54 ` [RFC PATCH 4/4] tests/acpi: Updated DSDT and SSDT due to move of PXB info to SSDT Jonathan Cameron via
2023-04-06 10:25 ` [RFC PATCH 0/4] hw/i386: Factor out PXB parts of DSDT into an SSDT table Jonathan Cameron via
2023-04-07  7:37   ` Michael S. Tsirkin
2023-04-11 14:02     ` Igor Mammedov [this message]
2023-04-11 14:05       ` Michael S. Tsirkin
2023-04-11 14:25         ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230411160219.64f0aa2f@imammedo.users.ipa.redhat.com \
    --to=imammedo@redhat.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=ani@anisinha.ca \
    --cc=berrange@redhat.com \
    --cc=dave.jiang@intel.com \
    --cc=fan.ni@samsung.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).