All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Gavin Shan <gshan@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@oss.qualcomm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org, alex@shazbot.org,
	richard.henderson@linaro.org, berrange@redhat.com,
	philmd@mailo.com, david@kernel.org, clg@redhat.com,
	pbonzini@redhat.com, phrdina@redhat.com, jugraham@redhat.com,
	liugang24219@sangfor.com.cn, dinghui@sangfor.com.cn,
	shan.gavin@gmail.com, qemu-s390x <qemu-s390x@nongnu.org>
Subject: Re: [PATCH v3 1/2] system/memory: Use qemu_ram_{copy, move}() in ram device region accessors
Date: Tue, 21 Jul 2026 12:27:54 -0400	[thread overview]
Message-ID: <al-eCtxGjG4HHEbl@x1.local> (raw)
In-Reply-To: <59882c5b-545d-4768-8bf4-723fed97a801@redhat.com>

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/20260617022330-mutt-send-email-mst@kernel.org/

  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?

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.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2026-07-21 16:29 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16  5:25 [PATCH v3 0/2] system/memory: Make ram device region directly accessible Gavin Shan
2026-06-16  5:25 ` [PATCH v3 1/2] system/memory: Use qemu_ram_{copy, move}() in ram device region accessors Gavin Shan
2026-06-16  6:17   ` Michael S. Tsirkin
2026-06-16  7:15     ` Gavin Shan
2026-06-16  9:51       ` Michael S. Tsirkin
2026-06-16 12:50         ` Ding Hui
2026-06-16 15:51           ` Michael S. Tsirkin
2026-06-16 23:01             ` Gavin Shan
2026-06-25 10:09   ` Peter Maydell
2026-06-25 11:07     ` Michael S. Tsirkin
2026-06-25 12:48       ` Peter Maydell
2026-06-25 13:23         ` Michael S. Tsirkin
2026-06-25 14:02           ` Peter Maydell
2026-06-25 14:52             ` Michael S. Tsirkin
2026-06-25 15:23               ` Peter Maydell
2026-06-25 16:47                 ` Michael S. Tsirkin
2026-06-25 18:40                   ` Peter Maydell
2026-06-26  0:07                     ` Gavin Shan
2026-07-09  9:52                       ` Gavin Shan
2026-07-17 13:23                         ` Michael S. Tsirkin
2026-07-17 13:26                           ` Michael S. Tsirkin
2026-07-17 13:49                           ` Peter Maydell
2026-07-17 13:55                             ` Michael S. Tsirkin
2026-07-20  9:12                               ` Philippe Mathieu-Daudé
2026-07-21  5:37                                 ` Gavin Shan
2026-07-21 16:27                                   ` Peter Xu [this message]
2026-07-22  0:53                                     ` Gavin Shan
2026-07-22  5:58                                       ` Michael S. Tsirkin
2026-07-22 16:41                                         ` Peter Xu
2026-06-26 10:48                     ` Michael S. Tsirkin
2026-06-16  5:25 ` [PATCH v3 2/2] system/memory: Make ram device region directly accessible Gavin Shan
2026-06-16  5:36 ` [PATCH v3 0/2] " Michael S. Tsirkin
2026-06-16  5:43   ` Gavin Shan
2026-06-16  5:40 ` Gavin Shan
2026-06-16  5:44   ` Michael S. Tsirkin
2026-06-17  2:35     ` Gavin Shan
2026-06-17  5:52       ` Michael S. Tsirkin
2026-06-17  7:00         ` Gavin Shan
2026-06-17  7:27           ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=al-eCtxGjG4HHEbl@x1.local \
    --to=peterx@redhat.com \
    --cc=alex@shazbot.org \
    --cc=berrange@redhat.com \
    --cc=clg@redhat.com \
    --cc=david@kernel.org \
    --cc=dinghui@sangfor.com.cn \
    --cc=gshan@redhat.com \
    --cc=jugraham@redhat.com \
    --cc=liugang24219@sangfor.com.cn \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@mailo.com \
    --cc=philmd@oss.qualcomm.com \
    --cc=phrdina@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=shan.gavin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.