Re: [PATCH RFC 0/4] RME-DA preparatory work
Pierrick Bouvier <[email protected]>
| Newsgroups | gmane.comp.emulators.qemu.block,gmane.comp.emulators.qemu |
|---|---|
| Message-ID | <[email protected]> |
Hi Jim, On 8/18/2026 6:31 AM, Jim MacArthur wrote: > This is a subset of patches from Gustavo Romero's SMMU DA branch work, > featuring patches from Pierrick Bouvier and Viresh Kumar. These add > capabilities to the PCIe root port and ICH9 SATA driver, and also refactor > some code in hw/pci/msi.c for future use. > > The goal here is to upstream work which is independent of Tao Tang's SMMU-V3 > patches, while those are being reviewed. If/when Tao Tang's patches are > accepted, we can proceed with the remainder of the SMMU DA work. > > I have spent some time understanding these patches and believe them to be > sensible, but some parts of them may be outside my understanding, hence the > RFC tag. In particular, we may be incorrectly advertising features here which > are not actually implemented; although this doesn't cause any problems I can > see with Linux or our test suites, I can quite easily set the feature flags to > zero and keep the code structure if that's a problem. > > Jim > > Signed-off-by: Jim MacArthur <[email protected]> > --- > Pierrick Bouvier (4): > hw/pci: add IDE + TEE capability to PCIe root port > sata: add SPDM + IDE + TEE pci support > hw/pci: add DVSEC RMEDA capability to PCIe root port > hw/pci/msi: extract msi_message_address_register > > hw/ide/ich.c | 72 +++++++++++++++++++++++++++++++++++++- > hw/pci-bridge/gen_pcie_root_port.c | 38 ++++++++++++++++++++ > hw/pci/msi.c | 19 ++++++---- > hw/pci/pcie.c | 15 ++++++++ > include/hw/pci/msi.h | 1 + > include/hw/pci/pcie.h | 3 ++ > include/hw/pci/pcie_regs.h | 8 +++++ > 7 files changed, 149 insertions(+), 7 deletions(-) > --- > base-commit: fa19879df1658f96ac07365fca8835b7decd6995 > change-id: 20260818-jmac-rme-da-prep-8096fc816eee > > Best regards, thanks for posting this work. I didn't send them at the time because there was unfortunately no way for our community to test them, and see how they are used. We're still in the same situation. Implementation is strongly coupled to the work we did with Mathieu Poirier for support RME DA with QEMU, which is coupled to current Arm RME DA implementation. This one is still a wip and not yet upstream (across kernel and firmwares). Mathieu has better information than me since he kept on following this. In particular, our choice to add capabilities to a SATA device is just a consequence of following what Arm did with FVP. nvme drives have other limitations with RME DA at the moment, and it's uncharted territory. That said, it should not hurt, since it just adds capabilities to existing devices, and if maintainers are ok, can make its way upstream. Thanks, Pierrick