Re: [PATCH v3 1/2] system/memory: Use qemu_ram_{copy, move}() in ram device region accessors
"Michael S. Tsirkin" <[email protected]>
| Newsgroups | org.nongnu.qemu-arm,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jul 22, 2026 at 10:53:27AM +1000, Gavin Shan wrote: > On 7/22/26 2:27 AM, Peter Xu wrote: > > On Tue, Jul 21, 2026 at 03:37:53PM +1000, Gavin Shan wrote: > > > If Peter is fine with two variants for x86 and non-x86 architectures. > > > I can post (v4) for further review. That will be something like below > > > and let me know if there are any other improvements are needed. > > > > I have a generic question on the "unaligned access for x86": I think the > > question is about the one Michael raised here on unaligned access may break > > x86 here: > > > > https://lore.kernel.org/qemu-devel/[email protected]/ > > > > 3. (theoretical concern) also on x86, unaligned accesses are > > possible on guest and host, so converting an unaligned access to a > > series of aligned ones can in theory break devices. > > > > Is that a real problem we need to consider, or can we start with unified > > approach and leave it for later? > > > > I'm leaving this question to Michael. Knowing what I know about hardware designers, it's something someone somewhere does) It can be made a separate patch, just to show - it should be all of ~10LOC. > > PS: I apologize if I missed important piece of info along the way; I didn't > > follow closely on the discussion on this topic in the past few weeks. > > > > One thing to mention is, what we change should only need to affect > > ram_device, AFAIU.. so most memcpy()/memmove() shouldn't be changed for any > > arch when it's pure RAM. > > > > It depends. This patch intends to fix issue [1] in the lower layer by using > the newly added accessors (qemu_ram_{copy, move}) on all directly accessible > regions including the regular (pure) RAM region. Otherwise, the newly added > accessors should be limited to ram_device regions only as you said. > > [1] https://lore.kernel.org/qemu-devel/[email protected]/ > > Thanks, > Gavin using memcpy()/memmove() to emulate guest's atomics is generally kinda broken. but yes there are architectures where doing it to device ram is more broken than doing it to regular ram. -- MST