Re: [PULL 00/10] Next patches

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!

-- 
Peter Xu