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: Mon, 2 Dec 2024 16:23:39 -0500 [thread overview]
Message-ID: <Z04lW_CdYBPJRah3@x1n> (raw)
In-Reply-To: <20241108032952.56692-3-tomoyuki.hirose@igel.co.jp>
On Fri, Nov 08, 2024 at 12:29:46PM +0900, Tomoyuki HIROSE wrote:
> The previous code ignored 'impl.unaligned' and handled unaligned
> accesses as is. But this implementation could not emulate specific
> registers of some devices that allow unaligned access such as xHCI
> Host Controller Capability Registers.
I have some comment that can be naive, please bare with me..
Firstly, could you provide an example in the commit message, of what would
start working after this patch?
IIUC things like read(addr=0x2, size=8) should already working before but
it'll be cut into 4 times read() over 2 bytes for unaligned=false, am I
right?
>
> This commit emulates an unaligned access with multiple aligned
> accesses. Additionally, the overwriting of the max access size is
> removed to retrive the actual max access size.
>
> Signed-off-by: Tomoyuki HIROSE <tomoyuki.hirose@igel.co.jp>
> ---
> system/memory.c | 147 ++++++++++++++++++++++++++++++++++++++---------
> system/physmem.c | 8 ---
> 2 files changed, 119 insertions(+), 36 deletions(-)
>
> diff --git a/system/memory.c b/system/memory.c
> index 85f6834cb3..c2164e6478 100644
> --- a/system/memory.c
> +++ b/system/memory.c
> @@ -518,27 +518,118 @@ static MemTxResult memory_region_write_with_attrs_accessor(MemoryRegion *mr,
> return mr->ops->write_with_attrs(mr->opaque, addr, tmp, size, attrs);
> }
>
> +typedef MemTxResult (*MemoryRegionAccessFn)(MemoryRegion *mr,
> + hwaddr addr,
> + uint64_t *value,
> + unsigned size,
> + signed shift,
> + uint64_t mask,
> + MemTxAttrs attrs);
> +
> +static MemTxResult access_emulation(hwaddr addr,
> + uint64_t *value,
> + unsigned int size,
> + unsigned int access_size_min,
> + unsigned int access_size_max,
> + MemoryRegion *mr,
> + MemTxAttrs attrs,
> + MemoryRegionAccessFn access_fn_read,
> + MemoryRegionAccessFn access_fn_write,
> + bool is_write)
> +{
> + hwaddr a;
> + uint8_t *d;
> + uint64_t v;
> + MemTxResult r = MEMTX_OK;
> + bool is_big_endian = memory_region_big_endian(mr);
> + void (*store)(void *, int, uint64_t) = is_big_endian ? stn_be_p : stn_le_p;
> + uint64_t (*load)(const void *, int) = is_big_endian ? ldn_be_p : ldn_le_p;
> + size_t access_size = MAX(MIN(size, access_size_max), access_size_min);
> + uint64_t access_mask = MAKE_64BIT_MASK(0, access_size * 8);
> + hwaddr round_down = mr->ops->impl.unaligned && addr + size <= mr->size ?
> + 0 : addr % access_size;
> + hwaddr start = addr - round_down;
> + hwaddr tail = addr + size <= mr->size ? addr + size : mr->size;
There're plenty of special considerations on addr+size over mr->size. It
was confusing to me at the 1st glance, because after we have MR pointer
logically we should have clamped the size to make sure it won't get more
than the mr->size, e.g. for address space accesses it should have happened
in address_space_translate_internal(), translating IOs in flatviews.
Then I noticed b242e0e0e2 ("exec: skip MMIO regions correctly in
cpu_physical_memory_write_rom_internal"), also the special handling of MMIO
in access sizes where it won't be clamped. Is this relevant to why
mr->size needs to be checked here, and is it intended to allow it to have
addr+size > mr->size?
If it's intended, IMHO it would be nice to add some comment explicitly or
mention it in the commit message. It might not be very straightforward to
see..
> + uint8_t data[16] = {0};
> + g_assert(size <= 8);
> +
> + for (a = start, d = data, v = 0; a < tail;
> + a += access_size, d += access_size, v = 0) {
> + r |= access_fn_read(mr, a, &v, access_size, 0, access_mask,
> + attrs);
> + store(d, access_size, v);
I'm slightly confused on what is the endianess of data[]. It uses store(),
so I think it means it follows the MR's endianess. But then..
> + }
> + if (is_write) {
> + stn_he_p(&data[round_down], size, load(value, size));
... here stn_he_p() should imply that data[] is using host endianess...
Meanwhile I wonder why value should be loaded by load() - value should
points to a u64 which is, IIUC, host-endian, while load() is using MR's
endianess..
I wonder if we could have data[] using host endianess always, then here:
stn_he_p(&data[round_down], size, *value);
> + for (a = start, d = data; a < tail;
> + a += access_size, d += access_size) {
> + v = load(d, access_size);
> + r |= access_fn_write(mr, a, &v, access_size, 0, access_mask,
> + attrs);
> + }
> + } else {
> + store(value, size, ldn_he_p(&data[round_down], size));
> + }
> +
> + return r;
Now when unaligned write, it'll read at most 16 byte out in data[], apply
the changes, and write back all 16 bytes down even if only 8 bytes are new.
Is this the intended behavior? When I was thinking impl.unaligned=true, I
thought the device should be able to process unaligned address in the MR
ops directly. But I could be totally wrong here, hence more of a pure
question..
> +}
> +
> +static bool is_access_fastpath(hwaddr addr,
> + unsigned int size,
> + unsigned int access_size_min,
> + unsigned int access_size_max,
> + MemoryRegion *mr)
> +{
> + size_t access_size = MAX(MIN(size, access_size_max), access_size_min);
> + hwaddr round_down = mr->ops->impl.unaligned && addr + size <= mr->size ?
> + 0 : addr % access_size;
> +
> + return round_down == 0 && access_size <= size;
Would it be more readable to rewrite this with some if clauses? Something
like:
is_access_fastpath()
{
size_t access_size = MAX(MIN(size, access_size_max), access_size_min);
if (access_size < access_size_min) {
return false;
}
if (mr->ops->impl.unaligned && (addr + size <= mr->size)) {
return true;
}
return addr % access_size;
}
> +}
> +
> +static MemTxResult access_fastpath(hwaddr addr,
> + uint64_t *value,
> + unsigned int size,
> + unsigned int access_size_min,
> + unsigned int access_size_max,
> + MemoryRegion *mr,
> + MemTxAttrs attrs,
> + MemoryRegionAccessFn fastpath)
> +{
> + MemTxResult r = MEMTX_OK;
> + size_t access_size = MAX(MIN(size, access_size_max), access_size_min);
> + uint64_t access_mask = MAKE_64BIT_MASK(0, access_size * 8);
> +
> + if (memory_region_big_endian(mr)) {
> + for (size_t i = 0; i < size; i += access_size) {
> + r |= fastpath(mr, addr + i, value, access_size,
> + (size - access_size - i) * 8, access_mask, attrs);
> + }
> + } else {
> + for (size_t i = 0; i < size; i += access_size) {
> + r |= fastpath(mr, addr + i, value, access_size,
> + i * 8, access_mask, attrs);
> + }
> + }
> +
> + return r;
> +}
> +
> static MemTxResult access_with_adjusted_size(hwaddr addr,
> uint64_t *value,
> unsigned size,
> unsigned access_size_min,
> unsigned access_size_max,
> - MemTxResult (*access_fn)
> - (MemoryRegion *mr,
> - hwaddr addr,
> - uint64_t *value,
> - unsigned size,
> - signed shift,
> - uint64_t mask,
> - MemTxAttrs attrs),
> + MemoryRegionAccessFn access_fn_read,
> + MemoryRegionAccessFn access_fn_write,
> + bool is_write,
> MemoryRegion *mr,
> MemTxAttrs attrs)
> {
> - uint64_t access_mask;
> - unsigned access_size;
> - unsigned i;
> MemTxResult r = MEMTX_OK;
> bool reentrancy_guard_applied = false;
> + MemoryRegionAccessFn access_fn_fastpath =
> + is_write ? access_fn_write : access_fn_read;
>
> if (!access_size_min) {
> access_size_min = 1;
> @@ -560,20 +651,16 @@ static MemTxResult access_with_adjusted_size(hwaddr addr,
> reentrancy_guard_applied = true;
> }
>
> - /* FIXME: support unaligned access? */
> - access_size = MAX(MIN(size, access_size_max), access_size_min);
> - access_mask = MAKE_64BIT_MASK(0, access_size * 8);
> - if (memory_region_big_endian(mr)) {
> - for (i = 0; i < size; i += access_size) {
> - r |= access_fn(mr, addr + i, value, access_size,
> - (size - access_size - i) * 8, access_mask, attrs);
> - }
> + if (is_access_fastpath(addr, size, access_size_min, access_size_max, mr)) {
> + r |= access_fastpath(addr, value, size,
> + access_size_min, access_size_max, mr, attrs,
> + access_fn_fastpath);
> } else {
> - for (i = 0; i < size; i += access_size) {
> - r |= access_fn(mr, addr + i, value, access_size, i * 8,
> - access_mask, attrs);
> - }
> + r |= access_emulation(addr, value, size,
> + access_size_min, access_size_max, mr, attrs,
> + access_fn_read, access_fn_write, is_write);
> }
> +
> if (mr->dev && reentrancy_guard_applied) {
> mr->dev->mem_reentrancy_guard.engaged_in_io = false;
> }
> @@ -1459,13 +1546,15 @@ static MemTxResult memory_region_dispatch_read1(MemoryRegion *mr,
> mr->ops->impl.min_access_size,
> mr->ops->impl.max_access_size,
> memory_region_read_accessor,
> - mr, attrs);
> + memory_region_write_accessor,
> + false, mr, attrs);
> } else {
> return access_with_adjusted_size(addr, pval, size,
> mr->ops->impl.min_access_size,
> mr->ops->impl.max_access_size,
> memory_region_read_with_attrs_accessor,
> - mr, attrs);
> + memory_region_write_with_attrs_accessor,
> + false, mr, attrs);
> }
> }
>
> @@ -1553,15 +1642,17 @@ MemTxResult memory_region_dispatch_write(MemoryRegion *mr,
> return access_with_adjusted_size(addr, &data, size,
> mr->ops->impl.min_access_size,
> mr->ops->impl.max_access_size,
> - memory_region_write_accessor, mr,
> - attrs);
> + memory_region_read_accessor,
> + memory_region_write_accessor,
> + true, mr, attrs);
> } else {
> return
> access_with_adjusted_size(addr, &data, size,
> mr->ops->impl.min_access_size,
> mr->ops->impl.max_access_size,
> + memory_region_read_with_attrs_accessor,
> memory_region_write_with_attrs_accessor,
> - mr, attrs);
> + true, mr, attrs);
> }
> }
>
> diff --git a/system/physmem.c b/system/physmem.c
> index dc1db3a384..ff444140a8 100644
> --- a/system/physmem.c
> +++ b/system/physmem.c
> @@ -2693,14 +2693,6 @@ int memory_access_size(MemoryRegion *mr, unsigned l, hwaddr addr)
> access_size_max = 4;
> }
>
> - /* Bound the maximum access by the alignment of the address. */
> - if (!mr->ops->impl.unaligned) {
> - unsigned align_size_max = addr & -addr;
> - if (align_size_max != 0 && align_size_max < access_size_max) {
> - access_size_max = align_size_max;
> - }
> - }
Could you explain why this needs to be removed?
Again, I was expecting the change was for a device that will have
unaligned==true first, so this shouldn't matter. Then I wonder why this
behavior needs change. But I could miss something.
Thanks,
> -
> /* Don't attempt accesses larger than the maximum. */
> if (l > access_size_max) {
> l = access_size_max;
> --
> 2.43.0
>
--
Peter Xu
next prev parent reply other threads:[~2024-12-02 21:24 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 [this message]
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
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=Z04lW_CdYBPJRah3@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).