[Withdrawn] [RFC PATCH v2 0/9] support unaligned access to xHCI Capability

chen CJ posted 9 patches 4 days, 9 hours ago
Only 0 patches received!
[Withdrawn] [RFC PATCH v2 0/9] support unaligned access to xHCI Capability
Posted by chen CJ 4 days, 9 hours ago
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
Re: [Withdrawn] [RFC PATCH v2 0/9] support unaligned access to xHCI Capability
Posted by Peter Maydell 4 days, 4 hours ago
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
Re: [Withdrawn] [RFC PATCH v2 0/9] support unaligned access to xHCI Capability
Posted by Peter Xu 2 days ago
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