Re: [PATCH v3 1/2] system/memory: Use qemu_ram_{copy, move}() in ram device region accessors

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Jun 25, 2026 at 04:23:47PM +0100, Peter Maydell wrote:
> On Thu, 25 Jun 2026 at 15:52, Michael S. Tsirkin <mst@redhat.com> wrote:
> > I think there is exactly 1 kinda reasonable case. A 2 byte read/write at
> > offset 0x1 within a dword. This maps nicely to even classical PCI byte
> > enable mechanism and so yes it works if your CPU can initiate these
> > things, and it's atomic.
> >
> > I tried reading LEDCTL on e1000e:
> >
> >        byte  @ 0xe00: 0x64
> >        byte  @ 0xe01: 0x2a
> >        byte  @ 0xe02: 0x00
> >        byte  @ 0xe03: 0x00
> >        word  @ 0xe00: 0x2a64
> >        word  @ 0xe01: 0x002a
> >
> > Works fine.
> 
> The e1000e datasheet actually documents what it does in this
> case (slightly surprising, since hardware engineers love to
> leave this kind of corner case undocumented):
> 
> # For registers that should be accessed as 32-bit double words,
> # partial writes (less than a 32-bit double word) does not take
> # effect (such as, the write is ignored).
> # Partial reads
> # return all 32 bits of data regardless of the byte enables.
> #
> # Note: Partial reads to clear-by-read registers (such as, ICR)
> # can have unexpected results since all 32 bits are actually read
> # regardless of the byte enables. Partial reads should not be done.
> 
> So for this specific device that access is out-of-spec.

You mean that access to clear by read should not be done, right?

> I guess what I'm wondering is: can we just have code
> that does an aligned exact-width access in the 1/2/4/8
> byte aligned case, and the host's best approximation to
> an unaligned exact-width access for the 2/4/8 byte
> unaligned case?

That's my idea, too.

> (so on sparc you get multiple smaller
> accesses, and on most archs including x86 and arm you
> get an unaligned load).

I thought unaligned load from uncacheable on arm is
also a fault?

> That would mean the guest could
> potentially provoke a fault on the load/store on an
> access to a passthrough device, but if you give the
> guest passthrough access it can very likely provoke
> a fault anyway, depending on exactly what the device is.
> 
> I think the most likely reason for an unaligned access
> in this codepath is "it's actually RAM, either really
> host RAM or else something memory-like in a BAR", and
> either way if the guest does a 4-byte unaligned access
> then doing a 4-byte unaligned access seems better than
> second-guessing it, even on non-x86.
> 
> -- PMM

Right though remember: whether it's RAM doesn't matter. What matters is
how we map it.  qemu might fault because it maps NC but guest maps
cacheable and it's ok.

But, all this in theory. At a high level, I personally think going with
what you propose as a 1st approximation is entirely reasonable, except
for one thing: we really should not crash qemu, since access can be from
guest userspace.

qemu should know how things are mapped, and predict it will fault.
Approximating by splitting in that case sounds reasonable.



-- 
MST