All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, Peter Xu <peterx@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@oss.qualcomm.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: Mon, 27 Jul 2026 13:38:29 +1000	[thread overview]
Message-ID: <c69250a2-e461-4484-ae66-80767744e6fb@redhat.com> (raw)
In-Reply-To: <20260724122956-mutt-send-email-mst@kernel.org>

On 7/25/26 2:31 AM, Michael S. Tsirkin wrote:
> On Fri, Jul 24, 2026 at 09:56:48AM -0400, Peter Xu wrote:
>> On Fri, Jul 24, 2026 at 11:42:09AM +1000, Gavin Shan wrote:
>>> On 7/23/26 11:46 PM, Peter Xu wrote:
>>>> On Thu, Jul 23, 2026 at 05:05:08AM -0400, Michael S. Tsirkin wrote:

[...]

>>>> We should have another option that is not arch-dependent but keep the
>>>> unaligned behavior.
>>>>
>>>> For current master, AFAIU we do unaligned access for both ram_device and
>>>> rest. Say, even with ram_device_mem_ops, it has both .unaligned=true for
>>>> both .valid & .impl.  I think it means indeed we have unaligned behavior
>>>> even for ram_device.  It also means what matters in regards to the Realtek
>>>> bug was only about aligned access (with subpage presence).
>>>>
>>>> I think it means we can always keep unaligned to stick with
>>>> memcpy()/memmove(), but only use atomic ops for the aligned cases of
>>>> 1/2/4/8.  With that, I think we can also remove ram_device_mem_ops and fix
>>>> the bounce buffer issue.
>>>>
>>>> I think it means we'll stick with memcpy()/memmove() for all archs for
>>>> unaligned, which is again not safe... but that can be an existing but
>>>> separate problem to solve too.
>>>>
>>>
>>> Lets see if Peter Maydell and Michael are happy with this option. At least,
>>> we will have unified qemu_ram_move() for all architectures with this option.
>>> Note that qemu_ram_copy() won't be needed.
>>>
>>> I'm putting note on what's to be done in (v4) if this option is to be picked
>>> up. Let me know if there are missed points. It's basically combing what's done
>>> by ram_device_mem_ops to upper layer (e.g. in qemu_ram_move()).
>>>
>>>    address_space_write
>>>      address_space_to_flatview
>>>      flatview_write
>>>        flatview_translate
>>>        flatview_write_continue
>>>          flatview_write_continue_step
>>>            memmove                     // (A) to replace it with qemu_ram_move()
>>>
>>> /**
>>>   * qemu_ram_move: move data to ramblock
>>>   *
>>>   * @dst: destination where the data is moved to
>>>   * @src: source where the data is moved from
>>>   * @n: length of data to be moved
>>>   *
>>>   * Move @n bytes from @src to @dst with the assumption that @src and @dst
>>>   * can overlap. The access is atomic if the source and destination buffer
>>>   * aren't overlapped for a well aligned and small-sized access. Otherwise,
>>>   * fall back to the standard memmove().
>>>   */
>>> static void qemu_ram_move(void *dst, const void *src, size_t n)
>>> {
>>>      uintptr_t test, len;
>>>
>>>      if (src == dst || n == 0) {
>>>          return;
>>>      }
>>>
>>>      /* Overlapped buffers */
> 
> 
> overlapping
> 

Corrected in v4.

https://lore.kernel.org/qemu-arm/20260727032649.145381-1-gshan@redhat.com/

>>>      if (src < (dst + n) && dst < (src + n)) {
>>
>> s/&&/||/?
>>
>> It's a bit weird to request memmove() for overlapped, e.g. I don't know if
>> P2P can overlap too when some fuzzer fills in some MMIO address shifted for
>> src/dst.. but I think I get what you want to simplify and it looks fine.
>>
>> Otherwise it looks good.
> 
> Why do we bother special casing overlapping buffers though?
> I do not get it, looks like rest of logic works exactly
> the same for overlapping and non.
> 

Indeed. The explicit check if src/dst are overlapping has been dropped in v4.

>>>          memmove(dst, src, n);
>>>          return;
>>>      }
>>>
>>>      test = (uintptr_t)src | (uintptr_t)dst | n;
>>>      len = test & -test;
>>>
>>>      /* Unaligned or oversized access */
>>>      if (n > 8 || len != n) {
>>>          memmove(dst, src, n);
>>>          return;
>>>      }
>>>
>>>      switch (len) {
>>>      case 1:
>>>          qatomic_set((uint8_t *)dst, qatomic_read((uint8_t *)src));
>>>          break;
>>>      case 2:
>>>          qatomic_set((uint16_t *)dst, qatomic_read((uint16_t *)src));
>>>          break;
>>>      case 4:
>>>          qatomic_set((uint32_t *)dst, qatomic_read((uint32_t *)src));
>>>          break;
>>>      case 8:
>>>          qatomic_set((uint64_t *)dst, qatomic_read((uint64_t *)src));
>>>          break;
>>>      default:
>>>          g_assert_not_reached();
>>>      }
>>> }
>>

[...]

Thanks,
Gavin



  reply	other threads:[~2026-07-27  3:39 UTC|newest]

Thread overview: 48+ 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
2026-07-22  0:53                                     ` Gavin Shan
2026-07-22  5:58                                       ` Michael S. Tsirkin
2026-07-22 16:41                                         ` Peter Xu
2026-07-23  6:04                                           ` Michael S. Tsirkin
2026-07-23  8:52                                             ` Philippe Mathieu-Daudé
2026-07-23  9:05                                               ` Michael S. Tsirkin
2026-07-23 13:46                                                 ` Peter Xu
2026-07-24  1:42                                                   ` Gavin Shan
2026-07-24 13:56                                                     ` Peter Xu
2026-07-24 16:31                                                       ` Michael S. Tsirkin
2026-07-27  3:38                                                         ` Gavin Shan [this message]
2026-07-27  3:35                                                       ` Gavin Shan
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=c69250a2-e461-4484-ae66-80767744e6fb@redhat.com \
    --to=gshan@redhat.com \
    --cc=alex@shazbot.org \
    --cc=berrange@redhat.com \
    --cc=clg@redhat.com \
    --cc=david@kernel.org \
    --cc=dinghui@sangfor.com.cn \
    --cc=jugraham@redhat.com \
    --cc=liugang24219@sangfor.com.cn \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --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.