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 07:40:29PM +0100, Peter Maydell wrote:
> On Thu, 25 Jun 2026 at 17:47, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > 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?
> 
> The datasheet is ambiguous about whether "Partial reads should
> not be done" is meant to apply generally or only to clear-by-read
> registers.


I mean it's in a note about clear-by-read registers. Seems unambigous.


> > > 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?
> 
> For Arm the distinction is not cacheable/uncacheable
> but Normal vs Device. (Device is essentially for things
> which are not RAM; Normal is for RAM and RAM-like things,
> and includes all of Normal Non-cacheable, Normal WT-Cacheable
> and Normal WB-Cacheable.) Things mapped as Normal memory
> don't generate unaligned faults (unless the guest turned them
> on deliberately). For Device memory, it is IMPLEMENTATION
> DEFINED whether you get an alignment fault or not if you
> map something as Device that could have handled unaligned
> accesses if you had mapped it as Normal.

Right. Sorry I was unclear. I was referring to pgprot_noncached in Linux.



> > > 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.
> 
> > 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.
> 
> If QEMU and the guest disagree about the memory attributes
> on Arm then we have already lost, because the architecture
> says that memory attribute mismatches result in a variety of
> undesirable effects including things like loss of cache coherency
> (i.e. read and writes via QEMU's NC mapping disagree with ones
> via the guest's cacheable mapping because the latter are hitting
> in the cache and the former are bypassing it).

But we don't know how guest mapped it, at least without
VFIO's help. I guess DMA into device BAR is just often broken
on ARM except if guest happens to use same attributes as
set up by vfio.


> > 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.
> 
> You can't prevent faults entirely, though -- if the device
> being mapped has e.g. behaviour that says "unaligned accesses
> will fault" and then the x86 guest does an unaligned access,
> then the device will trigger a fault,

I don't get this part. How can a device "trigger a fault" on the x86 CPU?
But on non x86 in theory yes software could want the fault.
Hopefully it does not.

> and the fault is what
> you want because it's what the guest would see on real h/w.
> Unfortunately we don't have a convenient way to feed the
> fault back to the guest.

I didn't check but I mean we could add it to kvm I am guessing, if we
want. A lot of work so I would maybe wait for an actual issue before
spending engineering time on this.

> At some level if you pass through
> host hardware you're relying on the guest to not do totally
> stupid things.

Indeed.

> thanks
> -- PMM