Date: Mon, 1 Jul 2024 15:54:41 -0700 From: Dan Williams To: , CC: , , Subject: [ACPI Code First ECN v4] "Extended-linear" addressing for direct-mapped memory-side caches Message-ID: <668333b17e4b2_5639294fd@dwillia2-xfh.jf.intel.com.notmuch> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Xref: photonic.trudheim.com org.kernel.vger.linux-cxl:29226 Newsgroups: org.kernel.vger.linux-cxl,org.kernel.vger.linux-acpi Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail # Title: "Extended-linear" addressing for direct-mapped memory-side caches # Status: v4 # Document: ACPI Specification 6.6 # License SPDX-License Identifier: CC-BY-4.0 # Submitter: * Sponsor: Dan Williams, Intel * Creators/Contributors: * Andy Rudoff, retired * Mahesh Natu, Intel * Ishwar Agarwal, Intel # Changelog * v4: Drop "improved cache utilization" claim (Jonathan) * v4: Clarify SPA vs HPA terminology * v4: Clarify possibility and difficulty of multiple CPER records to communicate aliases (Jonathan) * v4: Clarify that N is expected to be an integer ration of "near" to "far" memory. (Jonathan) * v3: Replace "Inclusive Linear" with "Extended-linear" term, and clarify the SPA vs HPA behavior of this cache addressing mode. (Jonathan) * v2: Clarify the "Inclusive" term as "including the capacity of the cache in the SRAT range length" * v2: Clarify that 0 is an undeclared / transparent Address Mode, and that Address Mode values other than 1 are Reserved. v3: http://lore.kernel.org/6650e4f835a0e_195e294a8@dwillia2-mobl3.amr.corp.intel.com.notmuch v2: http://lore.kernel.org/663ea70884cfd_db82d29414@dwillia2-xfh.jf.intel.com.notmuch # Summary of the Change Recall that one of the modes available with persistent memory (PMEM) was a direct-mapped memory-side cache where DDR-memory transparently cached PMEM. This article has more details: https://thessdguy.com/intels-optane-two-confusing-modes-part-2-memory-mode/ ...but the main takeaway of that article that is relevant for this ECN is: "[PMEM] is paired with a DRAM that behaves as a cache, and, like a cache, it is invisible to the user. [..] A typical system might combine a 64GB DRAM DIMM with a 512GB Optane DIMM, but the total memory size will appear to the software as only 512GB." Instead, this new "extended-linear" direct-mapped memory-side cache addressing mode would make the memory-size that appears to software in the above example as 576GB, an increase of addressable capacity. A primary motivation for updating HMAT to explicitly enumerate this addressing mode is due to the OSPM's increased role for RAS and address-translation with CXL topologies. With CXL and OS native RAS flows OSPM is responsible for understanding and navigating the relationship between System-Physical-Address (SPA) ranges published ACPI.SRAT.MemoryAffinity, Host-Physical-Address ranges (HPA) published in the ACPI.CEDT.CFMWS, and HPAs programmed in CXL memory expander endpoints. Enable an OSPM to enumerate that the capacity for a memory-side cache extends an SRAT range. Typically the "Memory Side Cache Size" enumerated in the HMAT is "excluded" from the SRAT range length because it is a transparent cache of the SRAT capacity. I.e. typical systems present 1:1 SPA:HPA, extended-linear memory-side-cache systems alias multiple SPAs to a single CXL HPA. The enumeration of this addressing mode enables OSPM-memory-RAS (Reliability, Availability, and Serviceability) flows. # Benefits of the Change Without this change an OSPM that encounters a memory-side cache configuration of DDR fronting CXL may not understand that an SRAT range extended by cache capacity should be maintained as one contiguous SPA range even though the CXL HPA decode configuration only maps a subset of the SRAT SPA range. In other words the memory-side-cache dynamically maps access to that SPA range to either a CXL or DDR HPA. Without this change the only way for system software to become aware of the fact that one memory poison event implicates multiple address locations would be for multiple error records (CPER) to be emitted per-poison consumption event. That may surprise existing OSPM implementations. With this change, the OSPM can enumerate aliases and take actions like quarantine / offline all the impacted aliased pages to prevent further consumption of poison, or run repair operations on all the affected targets. The OSPM is enabled to identify the HPA associated with a given CXL endpoint DPA event, and understand how SPAs map to CXL HPAs. # Impact of the Change The proposed "Address Mode" field consumes the 2 Reserved bytes following the "Cache Attributes" field in the "Memory Side Cache Information Structure". The default reserved value of 0 indicates the status quo of an undeclared addressing mode where the expectation is that it is safe to assume the cache-capacity is transparent to the SRAT range capacity. An OSPM that knows about new values can consider SPA to HPA relationships according to the address-layout definition proposed below. A legacy OSPM will ignore it as a Reserved field. # References * Compute Express Link Specification v3.1, # Detailed Description of the Change * Section Table 5.149: Memory Side Cache Information Structure redefine the 2 Reserved bytes starting at offset 28 as "Address Mode": * 0 - Reserved (Unknown Address Mode) * 1 - Extended-linear (N direct-map aliases linearly mapped) * 2..65535 - Reserved (Unknown Address Mode) * Extend the implementation note after Table 5.149 to explain how to interpret the "Extended-linear" mode. * When Address Mode is 1 'Extended-Linear' it indicates that the associated address range (SRAT.MemoryAffinityStructure.Length) is comprised of the backing store capacity extended by the cache capacity. It is arranged such that there are N directly addressable aliases of a given cacheline where N is an integer ratio of target memory proximity domain size and the memory side cache size. Where the N aliased addresses for a given cacheline all share the same result for the operation 'address modulo cache size'. This setting is only allowed when 'Cache Associativity' is 'Direct Map'." . From: "Xingtao Yao (Fujitsu)" To: "Jonathan.Cameron@huawei.com" , "dan.j.williams@intel.com" CC: "qemu-devel@nongnu.org" , "linux-cxl@vger.kernel.org" , "nvdimm@lists.linux.dev" Subject: [BUG REPORT] cxl process in infinity loop Date: Tue, 2 Jul 2024 00:30:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Xref: photonic.trudheim.com org.kernel.vger.linux-cxl:29227 Newsgroups: org.kernel.vger.linux-cxl,dev.linux.lists.nvdimm,org.nongnu.qemu-devel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail SGksIGFsbA0KDQpXaGVuIEkgZGlkIHRoZSBjeGwgbWVtb3J5IGhvdC1wbHVnIHRlc3Qgb24gUUVN VSwgSSBhY2NpZGVudGFsbHkgY29ubmVjdGVkIA0KdHdvIG1lbWRldiB0byB0aGUgc2FtZSBkb3du c3RyZWFtIHBvcnQsIHRoZSBjb21tYW5kIGxpa2UgYmVsb3c6DQoNCj4gLW9iamVjdCBtZW1vcnkt YmFja2VuZC1yYW0sc2l6ZT0yNjIxNDRrLHNoYXJlPW9uLGlkPXZtZW0wIFwNCj4gLW9iamVjdCBt ZW1vcnktYmFja2VuZC1yYW0sc2l6ZT0yNjIxNDRrLHNoYXJlPW9uLGlkPXZtZW0xIFwNCj4gLWRl dmljZSBweGItY3hsLGJ1c19ucj0xMixidXM9cGNpZS4wLGlkPWN4bC4xIFwNCj4gLWRldmljZSBj eGwtcnAscG9ydD0wLGJ1cz1jeGwuMSxpZD1yb290X3BvcnQwLGNoYXNzaXM9MCxzbG90PTAgXA0K PiAtZGV2aWNlIGN4bC11cHN0cmVhbSxidXM9cm9vdF9wb3J0MCxpZD11czAgXA0KPiAtZGV2aWNl IGN4bC1kb3duc3RyZWFtLHBvcnQ9MCxidXM9dXMwLGlkPXN3cG9ydDAwLGNoYXNzaXM9MCxzbG90 PTUgXA0KPiAtZGV2aWNlIGN4bC1kb3duc3RyZWFtLHBvcnQ9MCxidXM9dXMwLGlkPXN3cG9ydDAx LGNoYXNzaXM9MCxzbG90PTcgXA0Kc2FtZSBkb3duc3RyZWFtIHBvcnQgYnV0IGhhcyBkaWZmZXJl bnQgc2xvdCENCg0KPiAtZGV2aWNlIGN4bC10eXBlMyxidXM9c3dwb3J0MDAsdm9sYXRpbGUtbWVt ZGV2PXZtZW0wLGlkPWN4bC12bWVtMCBcDQo+IC1kZXZpY2UgY3hsLXR5cGUzLGJ1cz1zd3BvcnQw MSx2b2xhdGlsZS1tZW1kZXY9dm1lbTEsaWQ9Y3hsLXZtZW0xIFwNCj4gLU0gY3hsLWZtdy4wLnRh cmdldHMuMD1jeGwuMSxjeGwtZm13LjAuc2l6ZT02NEcsY3hsLWZtdy4wLmludGVybGVhdmUtZ3Jh bnVsYXJpdHk9NGsgXA0KDQpUaGVyZSBpcyBubyBlcnJvciBvY2N1cnJlZCB3aGVuIHZtIHN0YXJ0 LCBidXQgd2hlbiBJIGV4ZWN1dGVkIHRoZSDigJxjeGwgbGlzdOKAnSBjb21tYW5kIHRvIHZpZXcN CnRoZSBDWEwgb2JqZWN0cyBpbmZvLCB0aGUgcHJvY2VzcyBjYW4gbm90IGVuZCBwcm9wZXJseS4N Cg0KVGhlbiBJIHVzZWQgc3RyYWNlIHRvIHRyYWNlIHRoZSBwcm9jZXNzLCBJIGZvdW5kIHRoYXQg dGhlIHByb2Nlc3MgaXMgaW4gaW5maW5pdHkgbG9vcDoNCiMgc3RyYWNlIGN4bCBsaXN0DQouLi4u Li4NCmNsb2NrX25hbm9zbGVlcChDTE9DS19SRUFMVElNRSwgMCwge3R2X3NlYz0wLCB0dl9uc2Vj PTEwMDAwMDB9LCBOVUxMKSA9IDANCm9wZW5hdChBVF9GRENXRCwgIi9zeXMvYnVzL2N4bC9mbHVz aCIsIE9fV1JPTkxZfE9fQ0xPRVhFQykgPSAzDQp3cml0ZSgzLCAiMVxuXDAiLCAzKSAgICAgICAg ICAgICAgICAgICAgPSAzDQpjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PSAwDQphY2Nlc3MoIi9ydW4vdWRldi9xdWV1ZSIsIEZfT0spICAgICAgICAgPSAwDQpjbG9ja19u YW5vc2xlZXAoQ0xPQ0tfUkVBTFRJTUUsIDAsIHt0dl9zZWM9MCwgdHZfbnNlYz0xMDAwMDAwfSwg TlVMTCkgPSAwDQpvcGVuYXQoQVRfRkRDV0QsICIvc3lzL2J1cy9jeGwvZmx1c2giLCBPX1dST05M WXxPX0NMT0VYRUMpID0gMw0Kd3JpdGUoMywgIjFcblwwIiwgMykgICAgICAgICAgICAgICAgICAg ID0gMw0KY2xvc2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KYWNjZXNz KCIvcnVuL3VkZXYvcXVldWUiLCBGX09LKSAgICAgICAgID0gMA0KY2xvY2tfbmFub3NsZWVwKENM T0NLX1JFQUxUSU1FLCAwLCB7dHZfc2VjPTAsIHR2X25zZWM9MTAwMDAwMH0sIE5VTEwpID0gMA0K b3BlbmF0KEFUX0ZEQ1dELCAiL3N5cy9idXMvY3hsL2ZsdXNoIiwgT19XUk9OTFl8T19DTE9FWEVD KSA9IDMNCndyaXRlKDMsICIxXG5cMCIsIDMpICAgICAgICAgICAgICAgICAgICA9IDMNCmNsb3Nl KDMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDANCmFjY2VzcygiL3J1bi91ZGV2 L3F1ZXVlIiwgRl9PSykgICAgICAgICA9IDANCmNsb2NrX25hbm9zbGVlcChDTE9DS19SRUFMVElN RSwgMCwge3R2X3NlYz0wLCB0dl9uc2VjPTEwMDAwMDB9LCBOVUxMKSA9IDANCm9wZW5hdChBVF9G RENXRCwgIi9zeXMvYnVzL2N4bC9mbHVzaCIsIE9fV1JPTkxZfE9fQ0xPRVhFQykgPSAzDQp3cml0 ZSgzLCAiMVxuXDAiLCAzKSAgICAgICAgICAgICAgICAgICAgPSAzDQpjbG9zZSgzKSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPSAwDQphY2Nlc3MoIi9ydW4vdWRldi9xdWV1ZSIsIEZf T0spICAgICAgICAgPSAwDQpjbG9ja19uYW5vc2xlZXAoQ0xPQ0tfUkVBTFRJTUUsIDAsIHt0dl9z ZWM9MCwgdHZfbnNlYz0xMDAwMDAwfSwgTlVMTCkgPSAwDQpvcGVuYXQoQVRfRkRDV0QsICIvc3lz L2J1cy9jeGwvZmx1c2giLCBPX1dST05MWXxPX0NMT0VYRUMpID0gMw0Kd3JpdGUoMywgIjFcblww IiwgMykgICAgICAgICAgICAgICAgICAgID0gMw0KY2xvc2UoMykgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgID0gMA0KYWNjZXNzKCIvcnVuL3VkZXYvcXVldWUiLCBGX09LKSAgICAgICAg ID0gMA0KY2xvY2tfbmFub3NsZWVwKENMT0NLX1JFQUxUSU1FLCAwLCB7dHZfc2VjPTAsIHR2X25z ZWM9MTAwMDAwMH0sIE5VTEwpID0gMA0Kb3BlbmF0KEFUX0ZEQ1dELCAiL3N5cy9idXMvY3hsL2Zs dXNoIiwgT19XUk9OTFl8T19DTE9FWEVDKSA9IDMNCndyaXRlKDMsICIxXG5cMCIsIDMpICAgICAg ICAgICAgICAgICAgICA9IDMNCmNsb3NlKDMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA9IDANCmFjY2VzcygiL3J1bi91ZGV2L3F1ZXVlIiwgRl9PSykgICAgICAgICA9IDANCmNsb2Nr X25hbm9zbGVlcChDTE9DS19SRUFMVElNRSwgMCwge3R2X3NlYz0wLCB0dl9uc2VjPTEwMDAwMDB9 LCBOVUxMKSA9IDANCm9wZW5hdChBVF9GRENXRCwgIi9zeXMvYnVzL2N4bC9mbHVzaCIsIE9fV1JP TkxZfE9fQ0xPRVhFQykgPSAzDQp3cml0ZSgzLCAiMVxuXDAiLCAzKSAgICAgICAgICAgICAgICAg ICAgPSAzDQpjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwDQphY2Nl c3MoIi9ydW4vdWRldi9xdWV1ZSIsIEZfT0spICAgICAgICAgPSAwDQpjbG9ja19uYW5vc2xlZXAo Q0xPQ0tfUkVBTFRJTUUsIDAsIHt0dl9zZWM9MCwgdHZfbnNlYz0xMDAwMDAwfSwgTlVMTCkgPSAw DQpvcGVuYXQoQVRfRkRDV0QsICIvc3lzL2J1cy9jeGwvZmx1c2giLCBPX1dST05MWXxPX0NMT0VY RUMpID0gMw0Kd3JpdGUoMywgIjFcblwwIiwgMykgICAgICAgICAgICAgICAgICAgID0gMw0KY2xv c2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KYWNjZXNzKCIvcnVuL3Vk ZXYvcXVldWUiLCBGX09LKSAgICAgICAgID0gMA0KDQpbRW52aXJvbm1lbnRdOg0KbGludXg6IFY2 LjEwLXJjMw0KUUVNVTogVjkuMC4wDQpuZGN0bDogdjc5DQoNCkkga25vdyB0aGlzIGlzIGJlY2F1 c2Ugb2YgdGhlIHdyb25nIHVzZSBvZiB0aGUgUUVNVSBjb21tYW5kLCBidXQgSSB0aGluayB3ZSBz aG91bGQgDQpiZSBhd2FyZSBvZiB0aGlzIGVycm9yIGluIG9uZSBvZiB0aGUgUUVNVSwgT1Mgb3Ig bmRjdGwgc2lkZSBhdCBsZWFzdC4NCg0KVGhhbmtzDQpYaW5ndGFvDQo= . From: Jonathan Cameron To: , , Markus Armbruster , , , , , Richard Henderson CC: , Dave Jiang , Huang Ying , Paolo Bonzini , , , Michael Roth , Ani Sinha Subject: [PATCH v4 00/13] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Date: Tue, 2 Jul 2024 14:14:05 +0100 Message-ID: <20240702131428.664859-1-Jonathan.Cameron@huawei.com> X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.linux-cxl:29233 Newsgroups: org.kernel.vger.linux-cxl,org.nongnu.qemu-devel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Title becoming a little misleading as now this does a bunch of other stuff as precursors, but I've kept it to maintain association with v3 and before. A more accurate series title is probably acpi: Rework GI affinity structure generation, add GPs + complex NUMA test. Based-on: [PATCH v4 00/16] Add support for RISC-V ACPI tests patches 2-16 (1 is upstream) Note there is a test data error in there for riscv but that shouldn't affect this series. Chances since v3: Thanks to Igor for reviewing. - Rename to busnr the property for getting the bus number. - Make more use of acpi_uid property to reduce need for ACPI code to see PCI internals. Note there is much more to do here for other properties but I'd rather do that as a follow up set to avoid even more creep in what this set is covering. - Moves of test data due to basing on the above series. - Drop accidentally included unused files. - Misc minor fixes called out in individual patches. ACPI 6.5 introduced Generic Port Affinity Structures to close a system description gap that was a problem for CXL memory systems. It defines an new SRAT Affinity structure (and hence allows creation of an ACPI Proximity Node which can only be defined via an SRAT structure) for the boundary between a discoverable fabric and a non discoverable system interconnects etc. The HMAT data on latency and bandwidth is combined with discoverable information from the CXL bus (link speeds, lane counts) and CXL devices (switch port to port characteristics and USP to memory, via CDAT tables read from the device). QEMU has supported the rest of the elements of this chain for a while but now the kernel has caught up and we need the missing element of Generic Ports (this code has been used extensively in testing and debugging that kernel support, some resulting fixes currently under review). Generic Port Affinity Structures are very similar to the recently added Generic Initiator Affinity Structures (GI) so this series factors out and reuses much of that infrastructure for reuse There are subtle differences (beyond the obvious structure ID change). - The ACPI spec example (and linux kernel support) has a Generic Port not as associated with the CXL root port, but rather with the CXL Host bridge. As a result, an ACPI handle is used (rather than the PCI SBDF option for GIs). In QEMU the easiest way to get to this is to target the root bridge PCI Bus, and conveniently the root bridge bus number is used for the UID allowing us to construct an appropriate entry. A key addition of this series is a complex NUMA topology example that stretches the QEMU emulation code for GI, GP and nodes with just CPUS, just memory, just hot pluggable memory, mixture of memory and CPUs. A similar test showed up a few NUMA related bugs with fixes applied for 9.0 (note that one of these needs linux booted to identify that it rejects the HMAT table and this test is a regression test for the table generation only). https://lore.kernel.org/qemu-devel/2eb6672cfdaea7dacd8e9bb0523887f13b9f85ce.1710282274.git.mst@redhat.com/ https://lore.kernel.org/qemu-devel/74e2845c5f95b0c139c79233ddb65bb17f2dd679.1710282274.git.mst@redhat.com/ Jonathan Cameron (13): hw/acpi: Fix ordering of BDF in Generic Initiator PCI Device Handle. hw/acpi/GI: Fix trivial parameter alignment issue. hw/acpi: Move AML building code for Generic Initiators to aml_build.c hw/acpi: Rename build_all_acpi_generic_initiators() to build_acpi_generic_initiator() hw/pci: Add a busnr property to pci_props and use for acpi/gi acpi/pci: Move Generic Initiator object handling into acpi/pci.* hw/pci-bridge: Add acpi_uid property to TYPE_PXB_BUS hw/i386/acpi: Use TYPE_PXB_BUS property acpi_uid for DSDT hw/pci-host/gpex-acpi: Use acpi_uid property. hw/acpi: Generic Port Affinity Structure support bios-tables-test: Allow for new acpihmat-generic-x test data. bios-tables-test: Add complex SRAT / HMAT test for GI GP bios-tables-test: Add data for complex numa test (GI, GP etc) qapi/qom.json | 34 +++ include/hw/acpi/acpi_generic_initiator.h | 47 ---- include/hw/acpi/aml-build.h | 8 + include/hw/acpi/pci.h | 7 + include/hw/pci/pci_bridge.h | 1 + hw/acpi/acpi_generic_initiator.c | 148 ------------ hw/acpi/aml-build.c | 84 +++++++ hw/acpi/pci.c | 226 ++++++++++++++++++ hw/arm/virt-acpi-build.c | 3 +- hw/i386/acpi-build.c | 12 +- hw/pci-bridge/pci_expander_bridge.c | 12 +- hw/pci-host/gpex-acpi.c | 7 +- hw/pci/pci.c | 14 ++ tests/qtest/bios-tables-test.c | 97 ++++++++ hw/acpi/meson.build | 1 - .../data/acpi/x86/q35/APIC.acpihmat-generic-x | Bin 0 -> 136 bytes .../data/acpi/x86/q35/CEDT.acpihmat-generic-x | Bin 0 -> 68 bytes .../data/acpi/x86/q35/DSDT.acpihmat-generic-x | Bin 0 -> 10849 bytes .../data/acpi/x86/q35/HMAT.acpihmat-generic-x | Bin 0 -> 360 bytes .../data/acpi/x86/q35/SRAT.acpihmat-generic-x | Bin 0 -> 520 bytes 20 files changed, 495 insertions(+), 206 deletions(-) delete mode 100644 include/hw/acpi/acpi_generic_initiator.h delete mode 100644 hw/acpi/acpi_generic_initiator.c create mode 100644 tests/data/acpi/x86/q35/APIC.acpihmat-generic-x create mode 100644 tests/data/acpi/x86/q35/CEDT.acpihmat-generic-x create mode 100644 tests/data/acpi/x86/q35/DSDT.acpihmat-generic-x create mode 100644 tests/data/acpi/x86/q35/HMAT.acpihmat-generic-x create mode 100644 tests/data/acpi/x86/q35/SRAT.acpihmat-generic-x -- 2.43.0 . From: Jonathan Cameron To: , , Markus Armbruster , , Li Zhijian CC: Subject: [PATCH qemu 0/3] hw/cxl: Misc minor improvements Date: Tue, 2 Jul 2024 15:34:22 +0100 Message-ID: <20240702143425.717452-1-Jonathan.Cameron@huawei.com> X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.linux-cxl:29248 Newsgroups: org.kernel.vger.linux-cxl,org.nongnu.qemu-devel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Before pushing on to more significant features a few unrelated patches doing tidying up + one to avoid people setting the memory backend both for a CXL type 3 device and as normal RAM in an attempt to get SRAT to cover it correctly. We've had multiple 'bug' reports from this and if nothing else I'd like to stop getting those! Based on master + the two DCD series Michael Tsirkin has queued. Based-on: [PATCH v8 00/14] Enabling DCD emulation support in Qemu Based-on: https://lore.kernel.org/qemu-devel/20240523174651.1089554-1-nifan.cxl@gmail.com/ Based-on: [PATCH qemu 0/2] hw/cxl: DCD tweaks and improvements. Based-on: https://lore.kernel.org/qemu-devel/20240625170805.359278-1-Jonathan.Cameron@huawei.com/ Fan Ni (1): hw/cxl/cxl-mailbox-utils: remove unneeded mailbox output payload space zeroing Jonathan Cameron (1): hw/cxl: Check for multiple mappings of memory backends. Li Zhijian (1): hw/cxl: Get rid of unused cfmw_list include/hw/cxl/cxl.h | 1 - hw/cxl/cxl-host.c | 1 - hw/cxl/cxl-mailbox-utils.c | 7 ------- hw/mem/cxl_type3.c | 15 +++++++++++++++ 4 files changed, 15 insertions(+), 9 deletions(-) -- 2.43.0 .