qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Tomoyuki HIROSE <tomoyuki.hirose@igel.co.jp>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: [RFC PATCH 2/5] system/memory: support unaligned access
Date: Wed, 8 Jan 2025 11:50:03 -0500	[thread overview]
Message-ID: <Z36su8G_hlkdBFy6@x1n> (raw)
In-Reply-To: <2e2dba3c-2bfc-478a-988d-fbf2e58cc293@igel.co.jp>

Hi, Tomoyuki,

On Wed, Jan 08, 2025 at 11:58:10AM +0900, Tomoyuki HIROSE wrote:
> Happy new year, Peter.
> I had another job and was late in replying to your email, sorry.

Happy new year.  That's fine. :)

[...]

> > So.. it turns out we shouldn't drop impl.unaligned?  Because above two
> > seems to be the real user of such.  What we may want to do is:
> > 
> >    - Change above two use cases, adding impl.unaligned=true.
> > 
> >      This step should hopefully have zero effect in reality on the two
> >      devices.  One thing to mention is both of them do not look like to have
> >      an upper bound of max_access_size (either 8 which is the maximum, or
> >      not specified).
> 
> This might be a good way. In this way, we need to add 'impl.unaligned
> = true' to the xHCI Capability Register's MR. We also need to fix the

We need to keep xHCI's impl.unaligned to FALSE?  IIUC only if it's FALSE
would it start to use your new code in this series to automatically convert
the unaligned access request into one or multiple aligned accesses (without
changing xHCI's MR ops implementation, IOW resolve this in memory core).

I just had another look at your last patch:

https://lore.kernel.org/qemu-devel/20241108032952.56692-6-tomoyuki.hirose@igel.co.jp/

index d85adaca0d..f35cbe526f 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -3165,9 +3165,11 @@ static const MemoryRegionOps xhci_cap_ops = {
     .read = xhci_cap_read,
     .write = xhci_cap_write,
     .valid.min_access_size = 1,
-    .valid.max_access_size = 4,
+    .valid.max_access_size = 8,
+    .valid.unaligned = true,
     .impl.min_access_size = 4,
     .impl.max_access_size = 4,
+    .impl.unaligned = false,
     .endianness = DEVICE_LITTLE_ENDIAN,
 };

I think that should keep being valid.  So "valid.unaligned = true" will
start enable unaligned accesses from the API level which will start to
follow the xHCI controller's spec, then ".impl.unaligned = false" tells the
memory core to _not_ pass unaligned accesses to MR ops, instead break them
down properly.

> MR implementation to be safe when unaligned accessing (current xHCI
> implementation does not handle unaligned accesses but the spec allows
> unaligned accesses).
> 
> In addition, maybe it would be better to document the constraint that
> the situation where 'valid.unaligned = true' and 'impl.unaligned =
> false' is not supported.

Do you perhaps mean this instead?

  valid.unaligned = FALSE && impl.unaligned == TRUE

If so, I agree.  I think we could even consider adding an assertion into
memory_region_init_io() to make sure it won't be set.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2025-01-08 16:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08  3:29 [RFC PATCH 0/5] support unaligned access to xHCI Capability Tomoyuki HIROSE
2024-11-08  3:29 ` [RFC PATCH 1/5] hw/nvme/ctrl: specify the 'valid' field in MemoryRegionOps Tomoyuki HIROSE
2024-11-08  3:29 ` [RFC PATCH 2/5] system/memory: support unaligned access Tomoyuki HIROSE
2024-12-02 21:23   ` Peter Xu
2024-12-06  8:31     ` Tomoyuki HIROSE
2024-12-06 16:42       ` Peter Xu
2024-12-11  9:35         ` Tomoyuki HIROSE
2024-12-11 22:54           ` Peter Xu
2024-12-12  5:39             ` Tomoyuki HIROSE
2024-12-12 15:46               ` Peter Xu
2025-01-08  2:58                 ` Tomoyuki HIROSE
2025-01-08 16:50                   ` Peter Xu [this message]
2025-01-10 10:11                     ` Tomoyuki HIROSE
2025-01-10 15:08                       ` Peter Xu
2025-01-15  2:01                         ` Tomoyuki HIROSE
2024-12-11  9:56         ` Peter Maydell
2024-12-11 22:25           ` Peter Xu
2024-11-08  3:29 ` [RFC PATCH 3/5] hw/misc: add test device for memory access Tomoyuki HIROSE
2024-11-08  3:29 ` [RFC PATCH 4/5] tests/qtest: add test for memory region access Tomoyuki HIROSE
2024-11-08  3:29 ` [RFC PATCH 5/5] hw/usb/hcd-xhci: allow unaligned access to Capability Registers Tomoyuki HIROSE
2024-11-27  4:32 ` [RFC PATCH 0/5] support unaligned access to xHCI Capability Tomoyuki HIROSE
2024-11-27 11:23   ` Peter Maydell
2024-11-28  6:19     ` Tomoyuki HIROSE
2024-11-28 11:15       ` Peter Maydell
2024-11-29  3:33         ` Tomoyuki HIROSE
2024-12-02 14:17           ` Peter Maydell
2024-12-04 10:04             ` Tomoyuki HIROSE

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=Z36su8G_hlkdBFy6@x1n \
    --to=peterx@redhat.com \
    --cc=david@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=tomoyuki.hirose@igel.co.jp \
    /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).