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
