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 01:48:11PM +0100, Peter Maydell wrote:
> On Thu, 25 Jun 2026 at 12:07, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Jun 25, 2026 at 11:09:26AM +0100, Peter Maydell wrote:
> > > This is still wrong. We should not have "x86 magically works
> > > and all other hosts do something different" ifdefs. Define what
> > > semantics you need and then we can figure out how to
> > > implement them.
> > >
> > > My current thought is that we need to handle accesses of
> > > 1, 2, 4 and 8 bytes that are naturally aligned by ensuring that we
> > > do exactly one host load/store of that type, and that anything else
> > > is "the guest isn't relying on specific semantics here, we can just
> > > assume it's plain old RAM and do whatever". That would not
> > > require any architecture specific ifdefs.
> 
> > Well. X86 is special, as usual. It allows unaligned mmio so
> > we really have no way to know an x86 guest does not intend
> > just that. That can only be emulated perfectly on x86
> > which is sad but I see no reason to actively break it.
> 
> What actual hardware will rely on unaligned accesses
> appearing to it as single unaligned accesses?

/me shrugs
any hardware that was only tested under windows?

> And if we do need this, we need to specify:
> - what are the semantics we need to provide?

match what happens on bare metal

> - what is the use case that relies on these?
> Then we can see how closely we can match that.

passhtrough of weird devices, first of all.

> 
> There's a lot of extra complexity added in here for
> something it I don't think is ever going to matter,
> and having the most common host architecture take a
> totally different codepath from everything else is
> a recipe for that other codepath breaking.
> 
> -- PMM

Not sure we have to be pedantic. We have arch specific code and the
world did not end.  It's not a lot of code, it's just for unaligned
accesses on MMIO, which might or might not be broken anyway.
And it worked already, so it's more about going back to what we
did earlier.

-- 
MST