I would like to withdraw this patch series. Sorry for the inconvenience, and thank you for your understanding. CJ Chen <cjchen@igel.co.jp> 於 2025年8月22日 週五 下午6:25寫道: > > This patch set aims to support unaligned access to xHCI Capability > Registers. > > To achieve this, we introduce the emulation of an unaligned access > through multiple aligned accesses. This patch set also adds a test > device and several tests using this device to verify that the > emulation functions correctly. > > Using these changes, unaligned access to xHCI Capability Registers is > now supported. > > During development, I required a lot of 'MemoryRegionOps' structs with > its own read/write functions for tests. In the QEMU project, a large > number of similar functions or structs are often written in '.inc' > files. I followed this approach for the test functions but would > appreciate feedback on whether this is appropriate. > > --- > v1 ... v2: > - Fix the typo of ops size of big-l-valid. > - Replaced the huge macro blocks with dynamic loops that fill in > the `MemoryRegionOps` arrays at runtime. > - Remove test cases valid.unaligned = false,impl.unaligned = true. > - Modification to the memory document about the alignment issue. > - Update the npcm7xx_fiu, mx_pic and risc-v-iommu configuration > to align with the unaligned-access policy. > - Document memory.rst clarify that .valid=true,.impl=false causes > split unaligned accesses (may have side effects); forbid > .valid=false,.impl=true via assertion. > > --- > CJ Chen (4): > doc/devel/memory.rst: additional explanation for unaligned access > hw/riscv: iommu-trap: remove .impl.unaligned = true > hw: npcm7xx_fiu and mx_pic change .impl.unaligned = true > system/memory: assert on invalid unaligned combo > > Tomoyuki Hirose (5): > hw/nvme/ctrl: specify the 'valid' field in MemoryRegionOps > system/memory: support unaligned access > hw/usb/hcd-xhci: allow unaligned access to Capability Registers > hw/misc: add test device for memory access > tests/qtest: add test for memory region access > > docs/devel/memory.rst | 18 + > hw/misc/Kconfig | 4 + > hw/misc/memaccess-testdev.c | 331 +++++++++++++++ > hw/misc/meson.build | 1 + > hw/nvme/ctrl.c | 5 + > hw/riscv/riscv-iommu.c | 1 - > hw/ssi/npcm7xx_fiu.c | 3 + > hw/usb/hcd-xhci.c | 4 +- > hw/xtensa/mx_pic.c | 3 + > include/hw/misc/memaccess-testdev.h | 104 +++++ > system/memory.c | 148 +++++-- > system/physmem.c | 8 - > tests/qtest/memaccess-test.c | 597 ++++++++++++++++++++++++++++ > tests/qtest/meson.build | 9 + > 14 files changed, 1198 insertions(+), 38 deletions(-) > create mode 100644 hw/misc/memaccess-testdev.c > create mode 100644 include/hw/misc/memaccess-testdev.h > create mode 100644 tests/qtest/memaccess-test.c > > base-commit: 5836af0783213b9355a6bbf85d9e6bc4c9c9363f > -- > 2.25.1
On Wed, 3 Sept 2025 at 06:03, chen CJ <cjchen@igel.co.jp> wrote: > > I would like to withdraw this patch series. > > Sorry for the inconvenience, and thank you for your understanding. That's unfortunate; I think it's an issue we really do need to fix, but I entirely understand if you don't have the time to work on it further. I might pick it up if I have the time to do so. thanks -- PMM
On Wed, Sep 03, 2025 at 10:47:17AM +0100, Peter Maydell wrote: > On Wed, 3 Sept 2025 at 06:03, chen CJ <cjchen@igel.co.jp> wrote: > > > > I would like to withdraw this patch series. > > > > Sorry for the inconvenience, and thank you for your understanding. > > That's unfortunate; I think it's an issue we really do need to fix, > but I entirely understand if you don't have the time to work > on it further. > > I might pick it up if I have the time to do so. I worked on this problem a bit more in the past few days while almost everyone will be at the forum. It's almost because I saw similar issues that I have commented before on old versions, but they still existed in the core patch 5. Then I found more issues. Keep commenting on that might be awkward because there will be quite a few dependency changes. One example is, I kept thinking we should not worry about MMIO out-of-bound over mr->size when reaching as deep as access_with_adjusted_size(). There are still quite a few places in patch 5 of this series that does the calculation and it's not obvious what happens if mr->size violated. Peter, if you want to pick it up, please consider reading the replies I left in this series, alone with this version below as comparison reading material. The hope is the reworked patchset below _might_ be easier to read (at least I did add rich comments, because the unaligned changes are tricky and not easy to follow): https://gitlab.com/peterx/qemu/-/commits/mem-unaligned-fix-v0.1?ref_type=tags Especially this patch: https://gitlab.com/peterx/qemu/-/commit/8a8f0f5728a7adc6ecb2cf4358366d2d663a5ed9 However that won't pass the test cases. I still doubt the test case is wrong but I didn't go further modifying the test cases yet (or any better way to test this as you suggested in the other reply). I think that can be the 1st thing we figure out, not the best way to test, but the correctness of the current test case, because IIUC it shouldn't be relevant to impl of unaligned access. To me, if we can reach a consensus on what is the correct (test) behavior on all kinds of unaligned access emulations, fixing the impl should be relatively easy. Thanks, -- Peter Xu
© 2016 - 2025 Red Hat, Inc.