Re: [PULL 00/10] Next patches

[Peter Xu <peterx@redhat.com>]

On Thu, Aug 13, 2026 at 08:38:38AM -0400, Peter Xu wrote:
> On Wed, Aug 12, 2026 at 03:01:14PM -0700, Richard Henderson wrote:
> > On 8/12/26 08:14, Peter Xu wrote:
> > > The following changes since commit 84f07211cc5b4fc6a371559bf8a5de4fb068e648:
> > > 
> > >    Update version for v11.1.0 release (2026-08-11 10:04:46 -0400)
> > > 
> > > are available in the Git repository at:
> > > 
> > >    https://gitlab.com/peterx/qemu.git tags/next-pull-request
> > > 
> > > for you to fetch changes up to 2375e9b1239eb6ad794eaae29245b94f429c87c5:
> > > 
> > >    migration: Fix rare hang of migration_channel_read_peek() (2026-08-12 10:42:09 -0400)
> > > 
> > > ----------------------------------------------------------------
> > > migration/mem pull for 11.2
> > > 
> > > next 11.2:
> > > - Dongli's patch to add cpr-transfer support for HMP
> > > - Fabiano's doc update for migration on security issues
> > > - Gavin's fix for MMIO access support for memory APIs, reverting ram_device ops
> > > - Sam's migration test build fix for !ASN1
> > > - Peter's a few migration hardening fixes
> > 
> > MacOS build failures:
> > 
> > https://gitlab.com/qemu-project/qemu/-/jobs/15865084063
> > https://gitlab.com/qemu-project/qemu/-/jobs/15865084064
> > 
> > ../migration/ram.c:4291:54: error: incompatible pointer types passing
> > 'ram_addr_t *' (aka 'unsigned long *') to parameter of type 'uint64_t *'
> > (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types]
> >  4291 |         if (usub64_overflow(total_ram_bytes, length, &total_ram_bytes)) {
> >       |                                                      ^~~~~~~~~~~~~~~~
> > /Users/gitlab/builds/qemu-project/qemu/include/qemu/host-utils.h:552:70:
> > note: passing argument to parameter 'ret' here
> >   552 | static inline bool usub64_overflow(uint64_t x, uint64_t y, uint64_t *ret)
> >       |                                                                      ^
> > 
> > Note that ram_addr_t maps to uintptr_t not uint64_t.
> > Which should be functionally the same, but is probably
> > an 'unsigned long' vs 'unsigned long long' mismatch.
> > 
> > Perhaps we should just be using __builtin_add_overflow via a macro instead
> > of inlines so that we get the full functionality of the types accepted by
> > the builtin.
> 
> Ohhh I almost missed this email... somehow it lost all CCs include myself.
> I'll see how to fix and repost, thanks for the hints!

So for this one I plan to squash this (will repost in a minute):

diff --git a/migration/ram.c b/migration/ram.c
index 85feff578c..b6eb842746 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -4263,7 +4263,7 @@ static int parse_ramblock(QEMUFile *f, RAMBlock *block, ram_addr_t length)
     return ret;
 }

-static int parse_ramblocks(QEMUFile *f, ram_addr_t total_ram_bytes)
+static int parse_ramblocks(QEMUFile *f, uint64_t total_ram_bytes)
 {
     int ret = 0;

@@ -4271,7 +4271,7 @@ static int parse_ramblocks(QEMUFile *f, ram_addr_t total_ram_bytes)
     while (total_ram_bytes) {
         RAMBlock *block;
         char id[256];
-        ram_addr_t length;
+        uint64_t length;
         int len = qemu_get_byte(f);

         qemu_get_buffer(f, (uint8_t *)id, len);

After all, whole migration treats ram_addr_t to be u64, at least on wire.

For the long term, do we want to fully expose __builtin_add_overflow(), or
the new macro would do something more than what __builtin_add_overflow()
does?

Now when I think about it from the root, I tend to like what Xen defines
with ram_addr_t:

/* address in the RAM (different from a physical address) */
#if defined(CONFIG_XEN_BACKEND)
typedef uint64_t ram_addr_t;
#  define RAM_ADDR_MAX UINT64_MAX
#  define RAM_ADDR_FMT "%" PRIx64
#else
typedef uintptr_t ram_addr_t;
#  define RAM_ADDR_MAX UINTPTR_MAX
#  define RAM_ADDR_FMT "%" PRIxPTR
#endif

I don't know how we supported 32bit host emulating anything larger, but
logically it's doable, then IIUC uintptr_t won't be enough allocating
anything >4G? If emulating 64bits is too much, I still think it seems valid
to emulate e.g. PAE 36bits on a 32bit.  I didn't check how it was done now
or before, but logically it sounds that it should still work.

Meanwhile, we should never directly use a ram_addr_t* to be a pointer - it
simply is not, but only the address space qemu uses internally for
ramblocks.  That also implies to me that this seems to be a bit off.

Thanks,

-- 
Peter Xu