docs/system/security.rst | 22 +++++++++++--- include/system/memory.h | 46 ++++++++++++++++++++++------- hw/remote/vfio-user-obj.c | 4 +-- migration/channel.c | 11 +++++-- migration/migration-hmp-cmds.c | 18 ++++++++++++ migration/multifd-qatzip.c | 5 +++- migration/multifd-qpl.c | 24 +++++++++++++--- migration/multifd-uadk.c | 24 +++++++++++++--- migration/multifd-zlib.c | 11 ++++++- migration/multifd-zstd.c | 11 ++++++- migration/ram.c | 11 +++++-- system/memory.c | 41 +------------------------- system/physmem.c | 48 +++++++++++++++++++++++++++++-- tests/qtest/migration/tls-tests.c | 4 ++- hmp-commands.hx | 12 +++++--- system/trace-events | 2 -- 16 files changed, 214 insertions(+), 80 deletions(-)
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 ---------------------------------------------------------------- Dongli Zhang (1): migration/cpr: Add HMP support for cpr-transfer Fabiano Rosas (1): docs: Add security considerations for migration Gavin Shan (3): system/memory: Use memmove() for directly accessible regions system/memory: Use qemu_ram_move() for directly accessible regions system/memory: Make ram device region directly accessible Peter Xu (4): migration/multifd: Validate next_packet_size in zlib/zstd recv migration/multifd: Replace assert() with error_setg() in recv paths migration/ram: Check for RAMBlock size mismatch when parsing migration: Fix rare hang of migration_channel_read_peek() Sam Heney (1): tests/qtest/migration: Only build tls_no_hostname test with TASN1 docs/system/security.rst | 22 +++++++++++--- include/system/memory.h | 46 ++++++++++++++++++++++------- hw/remote/vfio-user-obj.c | 4 +-- migration/channel.c | 11 +++++-- migration/migration-hmp-cmds.c | 18 ++++++++++++ migration/multifd-qatzip.c | 5 +++- migration/multifd-qpl.c | 24 +++++++++++++--- migration/multifd-uadk.c | 24 +++++++++++++--- migration/multifd-zlib.c | 11 ++++++- migration/multifd-zstd.c | 11 ++++++- migration/ram.c | 11 +++++-- system/memory.c | 41 +------------------------- system/physmem.c | 48 +++++++++++++++++++++++++++++-- tests/qtest/migration/tls-tests.c | 4 ++- hmp-commands.hx | 12 +++++--- system/trace-events | 2 -- 16 files changed, 214 insertions(+), 80 deletions(-) -- 2.54.0
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.
r~
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
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
On 8/13/26 06:41, Peter Xu wrote: > 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? ram_addr_t != hwaddr or vaddr -- it's just an internal token. So a 32-bit machine could put 1G of ram (identified by ram_addr_t) at 8G (hwaddr) just fine. But obviously it couldn't put 8G of ram anywhere. :-) That said, Xen was weird in that it used to be possible to have an i386 qemu command-line talking to a x86_64 dom0 kernel controlling x86_64 guests. So, yeah, now we should drop this ram_addr_t distinction and always use uint64_t. r~
On 13/8/26 16:14, Richard Henderson wrote: > On 8/13/26 06:41, Peter Xu wrote: >> 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? > > ram_addr_t != hwaddr or vaddr -- it's just an internal token. > > So a 32-bit machine could put 1G of ram (identified by ram_addr_t) at 8G > (hwaddr) just fine. But obviously it couldn't put 8G of ram anywhere. :-) > > That said, Xen was weird in that it used to be possible to have an i386 > qemu command-line talking to a x86_64 dom0 kernel controlling x86_64 > guests. > > So, yeah, now we should drop this ram_addr_t distinction and always use > uint64_t. 🩷🩷🩷 lovely 🩷🩷🩷
On Thu, Aug 13, 2026 at 04:51:39PM +0200, Philippe Mathieu-Daudé wrote: > On 13/8/26 16:14, Richard Henderson wrote: > > On 8/13/26 06:41, Peter Xu wrote: > > > 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? > > > > ram_addr_t != hwaddr or vaddr -- it's just an internal token. > > > > So a 32-bit machine could put 1G of ram (identified by ram_addr_t) at 8G > > (hwaddr) just fine. But obviously it couldn't put 8G of ram anywhere. > > :-) Yep, I should have described it as allocating >4G in total, rather in one shot. So it's about the address space we can allocate that is limited.. > > > > That said, Xen was weird in that it used to be possible to have an i386 > > qemu command-line talking to a x86_64 dom0 kernel controlling x86_64 > > guests. > > > > So, yeah, now we should drop this ram_addr_t distinction and always use > > uint64_t. > > 🩷🩷🩷 lovely 🩷🩷🩷 I can throw a patch, just to double check one last thing: we don't support any form of 32bit hosts anymore, am I right? -- Peter Xu
On 13/8/26 17:05, Peter Xu wrote:
> On Thu, Aug 13, 2026 at 04:51:39PM +0200, Philippe Mathieu-Daudé wrote:
>> On 13/8/26 16:14, Richard Henderson wrote:
>>> On 8/13/26 06:41, Peter Xu wrote:
>>>> 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?
>>>
>>> ram_addr_t != hwaddr or vaddr -- it's just an internal token.
>>>
>>> So a 32-bit machine could put 1G of ram (identified by ram_addr_t) at 8G
>>> (hwaddr) just fine. But obviously it couldn't put 8G of ram anywhere.
>>> :-)
>
> Yep, I should have described it as allocating >4G in total, rather in one
> shot. So it's about the address space we can allocate that is limited..
>
>>>
>>> That said, Xen was weird in that it used to be possible to have an i386
>>> qemu command-line talking to a x86_64 dom0 kernel controlling x86_64
>>> guests.
>>>
>>> So, yeah, now we should drop this ram_addr_t distinction and always use
>>> uint64_t.
>>
>> 🩷🩷🩷 lovely 🩷🩷🩷
>
> I can throw a patch, just to double check one last thing: we don't support
> any form of 32bit hosts anymore, am I right?
commit 372ec46b9f1215f48a4717f2b7ed969f65bfadc6
Author: Richard Henderson <richard.henderson@linaro.org>
Date: Thu Dec 18 09:56:27 2025 +1100
meson: Reject 32-bit hosts
32-bit hosts have been deprecated since 10.0.
diff --git a/docs/about/removed-features.rst
b/docs/about/removed-features.rst
+32-bit host operating systems (removed in 11.0)
+'''''''''''''''''''''''''''''''''''''''''''''''
© 2016 - 2026 Red Hat, Inc.