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

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

On Tue, Jun 16, 2026 at 03:21:58PM +1000, Gavin Shan wrote:
> On 6/16/26 3:17 PM, Michael S. Tsirkin wrote:
> > On Tue, Jun 16, 2026 at 02:55:52PM +1000, Gavin Shan wrote:
> > > On 6/16/26 2:49 PM, Michael S. Tsirkin wrote:
> > > > On Mon, Jun 15, 2026 at 09:48:00PM -0700, Richard Henderson wrote:
> > > > > On 6/15/26 21:23, Michael S. Tsirkin wrote:
> > > > > > B. Also on x86, I do not see why we should not use memcpy for large
> > > > > > accesses if we can. Better perf.
> > > > > 
> > > > > We have an example where memcpy writes to the same location 3 times.
> > > > > This is not appropriate for any host.
> > > > > 
> > > > > 
> > > > > r~
> > > > 
> > > > as in, same byte?  could you share the details pls?
> > > > 
> > > 
> > > This issue happened on aarch64 only.
> > > 
> > > https://lore.kernel.org/qemu-devel/CAFEAcA8dwHV8F48kb-013rxkG9kKcZhym9_qarKmoeUfeh0YWw@mail.gmail.com/
> > > 
> > > Thanks,
> > > Gavin
> > 
> > oh wow. thanks for sharing!
> > 
> > Still I think for sizes outside of 2,4,8 it's fine?
> > That is where the perf is.
> > 
> 
> For that point, I agree with you that it's fine to use memcpy/memmove
> when the length is 16-bytes or more,
> unless Richard is concerned by
> this.

yea size cutoff is a heuristic but i guess it's the best we can do.  or
disable memcpy completely if Richard feels strongly about it. But it
seems like a waste.


> I'm posting (v3) and lets continue the discussion on (v3) series. Sorry
> for taking your guys so many time to review and discuss ;-)
> 
> Thanks,
> Gavin
> 


pls do include the list of issues and high level solution in the cover
letter though.