[PATCH 0/7] backends/hostmem: Make QOM types and properties unconditional

[PATCH 0/7] backends/hostmem: Make QOM types and properties unconditional

[Markus Armbruster]

I recently checked qom introspection for dangling child and link
types, and found one from sgx-epc to memory-backend-epc.  I reported

    Subject: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc
    Date: Thu, 22 Oct 2026 14:58:16 +0200
    Message-ID: <87zew5j3iv.fsf@pond.sub.org>

Daniel identified why: we register QOM type "memory-backend-epc"
conditionally.  He called that "rather dubious".  We found similar
conditional registration of "hostmem-memfd".

This series makes them both unconditional, along with a two class
properties.  It also improves error reporting.

Markus Armbruster (7):
  backends/hostmem: Drop redundant validation of property "size"
  backends/hostmem-file: Drop useless validation of property "mem-path"
  backends/hostmem: Improve error reporting when method alloc() fails
  backends/hostmem-epc: Register QOM type unconditionally
  backends/hostmem-memfd: Register QOM type unconditionally
  util/memfd: Improve error message when memfd_create() fails
  backends/hostmem-memfd: Add huge TLB properties unconditionally

 backends/hostmem-epc.c   | 12 +-----------
 backends/hostmem-file.c  |  9 ---------
 backends/hostmem-memfd.c | 35 +++++++++++++----------------------
 backends/hostmem-ram.c   |  5 -----
 backends/hostmem-shm.c   |  7 +------
 backends/hostmem.c       |  3 +++
 util/memfd.c             |  5 ++++-
 7 files changed, 22 insertions(+), 54 deletions(-)

-- 
2.55.0

[PATCH 1/7] backends/hostmem: Drop redundant validation of property "size"

[Markus Armbruster]

Property "size" is mandatory, and its setter
host_memory_backend_set_size() rejects value zero.  Delete the
redundant checks for zero in the .alloc() callbacks.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 backends/hostmem-epc.c   | 5 -----
 backends/hostmem-file.c  | 4 ----
 backends/hostmem-memfd.c | 5 -----
 backends/hostmem-ram.c   | 5 -----
 backends/hostmem-shm.c   | 5 -----
 5 files changed, 24 deletions(-)

diff --git a/backends/hostmem-epc.c b/backends/hostmem-epc.c
index ab20b182331..e1c784249ff 100644
--- a/backends/hostmem-epc.c
+++ b/backends/hostmem-epc.c
@@ -24,11 +24,6 @@ sgx_epc_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
     uint32_t ram_flags;
     int fd;
 
-    if (!backend->size) {
-        error_setg(errp, "can't create backend with size 0");
-        return false;
-    }
-
     fd = qemu_open("/dev/sgx_vepc", O_RDWR, errp);
     if (fd < 0) {
         return false;
diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index 6ad9cad0320..08d0382d76f 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -48,10 +48,6 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
     g_autofree gchar *name = NULL;
     uint32_t ram_flags;
 
-    if (!backend->size) {
-        error_setg(errp, "can't create backend with size 0");
-        return false;
-    }
     if (!fb->mem_path) {
         error_setg(errp, "mem-path property not set");
         return false;
diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
index 46489212a23..11d456e3ebd 100644
--- a/backends/hostmem-memfd.c
+++ b/backends/hostmem-memfd.c
@@ -49,11 +49,6 @@ memfd_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
     int fd = cpr_find_fd(name, 0);
     uint32_t ram_flags;
 
-    if (!backend->size) {
-        error_setg(errp, "can't create backend with size 0");
-        return false;
-    }
-
     if (fd >= 0) {
         goto have_fd;
     }
diff --git a/backends/hostmem-ram.c b/backends/hostmem-ram.c
index 6a507fad77c..0ae7b4ae759 100644
--- a/backends/hostmem-ram.c
+++ b/backends/hostmem-ram.c
@@ -22,11 +22,6 @@ ram_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
     g_autofree char *name = NULL;
     uint32_t ram_flags;
 
-    if (!backend->size) {
-        error_setg(errp, "can't create backend with size 0");
-        return false;
-    }
-
     name = host_memory_backend_get_name(backend);
     ram_flags = backend->share ? RAM_SHARED : RAM_PRIVATE;
     ram_flags |= backend->reserve ? 0 : RAM_NORESERVE;
diff --git a/backends/hostmem-shm.c b/backends/hostmem-shm.c
index adf60957c3c..0a01c760551 100644
--- a/backends/hostmem-shm.c
+++ b/backends/hostmem-shm.c
@@ -30,11 +30,6 @@ shm_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
     uint32_t ram_flags;
     int fd = cpr_find_fd(backend_name, 0);
 
-    if (!backend->size) {
-        error_setg(errp, "can't create shm backend with size 0");
-        return false;
-    }
-
     if (!backend->share) {
         error_setg(errp, "can't create shm backend with `share=off`");
         return false;
-- 
2.55.0

Re: [PATCH 1/7] backends/hostmem: Drop redundant validation of property "size"

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 01:23:36PM +0100, Markus Armbruster wrote:
> Property "size" is mandatory, and its setter
> host_memory_backend_set_size() rejects value zero.  Delete the
> redundant checks for zero in the .alloc() callbacks.
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>  backends/hostmem-epc.c   | 5 -----
>  backends/hostmem-file.c  | 4 ----
>  backends/hostmem-memfd.c | 5 -----
>  backends/hostmem-ram.c   | 5 -----
>  backends/hostmem-shm.c   | 5 -----
>  5 files changed, 24 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

...it is a shame this was/is dead code, since the actual error message
from host_memory_backend_set_size() is (IMHO) worse than that from the
unreachable code you're deleting

  $ ./build/qemu-system-x86_64 -object memory-backend-ram,size=0,id=foo
  qemu-system-x86_64: property 'size' of memory-backend-ram doesn't take value '0'

as a separate patch I might suggest

    diff --git a/backends/hostmem.c b/backends/hostmem.c
    index 173d042be35..f523dce6eb0 100644
    --- a/backends/hostmem.c
    +++ b/backends/hostmem.c
    @@ -77,8 +77,8 @@ host_memory_backend_set_size(Object *obj, Visitor *v, const char *name,
         }
         if (!value) {
             error_setg(errp,
    -                   "property '%s' of %s doesn't take value '%" PRIu64 "'",
    -                   name, object_get_typename(obj), value);
    +                   "cannot create '%s' with a size of 0",
    +                   object_get_typename(obj));
             return;
         }
         backend->size = value;

so that we get the nicer message:

    $ ./build/qemu-system-x86_64 -object memory-backend-ram,size=0,id=foo
    qemu-system-x86_64: cannot create 'memory-backend-ram' with a size of 0


> 
> diff --git a/backends/hostmem-epc.c b/backends/hostmem-epc.c
> index ab20b182331..e1c784249ff 100644
> --- a/backends/hostmem-epc.c
> +++ b/backends/hostmem-epc.c
> @@ -24,11 +24,6 @@ sgx_epc_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>      uint32_t ram_flags;
>      int fd;
>  
> -    if (!backend->size) {
> -        error_setg(errp, "can't create backend with size 0");
> -        return false;
> -    }
> -
>      fd = qemu_open("/dev/sgx_vepc", O_RDWR, errp);
>      if (fd < 0) {
>          return false;
> diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
> index 6ad9cad0320..08d0382d76f 100644
> --- a/backends/hostmem-file.c
> +++ b/backends/hostmem-file.c
> @@ -48,10 +48,6 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>      g_autofree gchar *name = NULL;
>      uint32_t ram_flags;
>  
> -    if (!backend->size) {
> -        error_setg(errp, "can't create backend with size 0");
> -        return false;
> -    }
>      if (!fb->mem_path) {
>          error_setg(errp, "mem-path property not set");
>          return false;
> diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
> index 46489212a23..11d456e3ebd 100644
> --- a/backends/hostmem-memfd.c
> +++ b/backends/hostmem-memfd.c
> @@ -49,11 +49,6 @@ memfd_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>      int fd = cpr_find_fd(name, 0);
>      uint32_t ram_flags;
>  
> -    if (!backend->size) {
> -        error_setg(errp, "can't create backend with size 0");
> -        return false;
> -    }
> -
>      if (fd >= 0) {
>          goto have_fd;
>      }
> diff --git a/backends/hostmem-ram.c b/backends/hostmem-ram.c
> index 6a507fad77c..0ae7b4ae759 100644
> --- a/backends/hostmem-ram.c
> +++ b/backends/hostmem-ram.c
> @@ -22,11 +22,6 @@ ram_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>      g_autofree char *name = NULL;
>      uint32_t ram_flags;
>  
> -    if (!backend->size) {
> -        error_setg(errp, "can't create backend with size 0");
> -        return false;
> -    }
> -
>      name = host_memory_backend_get_name(backend);
>      ram_flags = backend->share ? RAM_SHARED : RAM_PRIVATE;
>      ram_flags |= backend->reserve ? 0 : RAM_NORESERVE;
> diff --git a/backends/hostmem-shm.c b/backends/hostmem-shm.c
> index adf60957c3c..0a01c760551 100644
> --- a/backends/hostmem-shm.c
> +++ b/backends/hostmem-shm.c
> @@ -30,11 +30,6 @@ shm_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>      uint32_t ram_flags;
>      int fd = cpr_find_fd(backend_name, 0);
>  
> -    if (!backend->size) {
> -        error_setg(errp, "can't create shm backend with size 0");
> -        return false;
> -    }
> -
>      if (!backend->share) {
>          error_setg(errp, "can't create shm backend with `share=off`");
>          return false;
> -- 
> 2.55.0
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 1/7] backends/hostmem: Drop redundant validation of property "size"

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Nov 11, 2026 at 01:23:36PM +0100, Markus Armbruster wrote:
>> Property "size" is mandatory, and its setter
>> host_memory_backend_set_size() rejects value zero.  Delete the
>> redundant checks for zero in the .alloc() callbacks.
>> 
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> ---
>>  backends/hostmem-epc.c   | 5 -----
>>  backends/hostmem-file.c  | 4 ----
>>  backends/hostmem-memfd.c | 5 -----
>>  backends/hostmem-ram.c   | 5 -----
>>  backends/hostmem-shm.c   | 5 -----
>>  5 files changed, 24 deletions(-)
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>
> ...it is a shame this was/is dead code, since the actual error message
> from host_memory_backend_set_size() is (IMHO) worse than that from the
> unreachable code you're deleting
>
>   $ ./build/qemu-system-x86_64 -object memory-backend-ram,size=0,id=foo
>   qemu-system-x86_64: property 'size' of memory-backend-ram doesn't take value '0'

Fair point.

> as a separate patch I might suggest
>
>     diff --git a/backends/hostmem.c b/backends/hostmem.c
>     index 173d042be35..f523dce6eb0 100644
>     --- a/backends/hostmem.c
>     +++ b/backends/hostmem.c
>     @@ -77,8 +77,8 @@ host_memory_backend_set_size(Object *obj, Visitor *v, const char *name,
           if (host_memory_backend_mr_inited(backend)) {
               error_setg(errp, "cannot change property %s of %s ", name,
                          object_get_typename(obj));
               return;
           }

           if (!visit_type_size(v, name, &value, errp)) {
               return;
>          }
>          if (!value) {
>              error_setg(errp,
>     -                   "property '%s' of %s doesn't take value '%" PRIu64 "'",
>     -                   name, object_get_typename(obj), value);
>     +                   "cannot create '%s' with a size of 0",
>     +                   object_get_typename(obj));
>              return;
>          }
>          backend->size = value;
>
> so that we get the nicer message:
>
>     $ ./build/qemu-system-x86_64 -object memory-backend-ram,size=0,id=foo
>     qemu-system-x86_64: cannot create 'memory-backend-ram' with a size of 0

Your message assumes that the property is only ever set on behalf of an
object creation request.  Not true in general, qom-set exists.  I
believe it's true here due to the host_memory_backend_mr_inited() guard.
But that's not entirely obvious, isn't it?

Possible phrasings that don't assume this:

   property 'size' of 'memory-backend-ram' cannot be zero
   cannot set property 'size' of 'memory-backend-ram' to zero

Is one of them good enough?  I doubt this error is common.

There are enough "doesn't take value" error messages elsewhere to
justify a small series of its own.

Re: [PATCH 1/7] backends/hostmem: Drop redundant validation of property "size"

[Daniel P. Berrangé]

On Thu, Nov 12, 2026 at 08:44:28AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Wed, Nov 11, 2026 at 01:23:36PM +0100, Markus Armbruster wrote:
> >> Property "size" is mandatory, and its setter
> >> host_memory_backend_set_size() rejects value zero.  Delete the
> >> redundant checks for zero in the .alloc() callbacks.
> >> 
> >> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> >> ---
> >>  backends/hostmem-epc.c   | 5 -----
> >>  backends/hostmem-file.c  | 4 ----
> >>  backends/hostmem-memfd.c | 5 -----
> >>  backends/hostmem-ram.c   | 5 -----
> >>  backends/hostmem-shm.c   | 5 -----
> >>  5 files changed, 24 deletions(-)
> >
> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> >
> > ...it is a shame this was/is dead code, since the actual error message
> > from host_memory_backend_set_size() is (IMHO) worse than that from the
> > unreachable code you're deleting
> >
> >   $ ./build/qemu-system-x86_64 -object memory-backend-ram,size=0,id=foo
> >   qemu-system-x86_64: property 'size' of memory-backend-ram doesn't take value '0'
> 
> Fair point.
> 
> > as a separate patch I might suggest
> >
> >     diff --git a/backends/hostmem.c b/backends/hostmem.c
> >     index 173d042be35..f523dce6eb0 100644
> >     --- a/backends/hostmem.c
> >     +++ b/backends/hostmem.c
> >     @@ -77,8 +77,8 @@ host_memory_backend_set_size(Object *obj, Visitor *v, const char *name,
>            if (host_memory_backend_mr_inited(backend)) {
>                error_setg(errp, "cannot change property %s of %s ", name,
>                           object_get_typename(obj));
>                return;
>            }
> 
>            if (!visit_type_size(v, name, &value, errp)) {
>                return;
> >          }
> >          if (!value) {
> >              error_setg(errp,
> >     -                   "property '%s' of %s doesn't take value '%" PRIu64 "'",
> >     -                   name, object_get_typename(obj), value);
> >     +                   "cannot create '%s' with a size of 0",
> >     +                   object_get_typename(obj));
> >              return;
> >          }
> >          backend->size = value;
> >
> > so that we get the nicer message:
> >
> >     $ ./build/qemu-system-x86_64 -object memory-backend-ram,size=0,id=foo
> >     qemu-system-x86_64: cannot create 'memory-backend-ram' with a size of 0
> 
> Your message assumes that the property is only ever set on behalf of an
> object creation request.  Not true in general, qom-set exists.  I
> believe it's true here due to the host_memory_backend_mr_inited() guard.
> But that's not entirely obvious, isn't it?
> 
> Possible phrasings that don't assume this:
> 
>    property 'size' of 'memory-backend-ram' cannot be zero
>    cannot set property 'size' of 'memory-backend-ram' to zero
> 
> Is one of them good enough?  I doubt this error is common.

I'm fine with either of those, perhaps mildly leaning towards
the second.

> There are enough "doesn't take value" error messages elsewhere to
> justify a small series of its own.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 1/7] backends/hostmem: Drop redundant validation of property "size"

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Nov 12, 2026 at 08:44:28AM +0100, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:

[...]

>> > as a separate patch I might suggest

[...]

>> > so that we get the nicer message:
>> >
>> >     $ ./build/qemu-system-x86_64 -object memory-backend-ram,size=0,id=foo
>> >     qemu-system-x86_64: cannot create 'memory-backend-ram' with a size of 0
>> 
>> Your message assumes that the property is only ever set on behalf of an
>> object creation request.  Not true in general, qom-set exists.  I
>> believe it's true here due to the host_memory_backend_mr_inited() guard.
>> But that's not entirely obvious, isn't it?
>> 
>> Possible phrasings that don't assume this:
>> 
>>    property 'size' of 'memory-backend-ram' cannot be zero
>>    cannot set property 'size' of 'memory-backend-ram' to zero
>> 
>> Is one of them good enough?  I doubt this error is common.
>
> I'm fine with either of those, perhaps mildly leaning towards
> the second.
>
>> There are enough "doesn't take value" error messages elsewhere to
>> justify a small series of its own.

Just posted:

    From: Markus Armbruster <armbru@redhat.com>
    Subject: [PATCH] error: Improve a few error messages on setting property to zero
    Date: Thu, 12 Nov 2026 12:47:02 +0100
    Message-ID: <20261112114702.969681-1-armbru@redhat.com>

Re: [PATCH 1/7] backends/hostmem: Drop redundant validation of property "size"

[Mark Cave-Ayland]

On 11/11/2026 12:23, Markus Armbruster wrote:

> Property "size" is mandatory, and its setter
> host_memory_backend_set_size() rejects value zero.  Delete the
> redundant checks for zero in the .alloc() callbacks.
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>   backends/hostmem-epc.c   | 5 -----
>   backends/hostmem-file.c  | 4 ----
>   backends/hostmem-memfd.c | 5 -----
>   backends/hostmem-ram.c   | 5 -----
>   backends/hostmem-shm.c   | 5 -----
>   5 files changed, 24 deletions(-)
> 
> diff --git a/backends/hostmem-epc.c b/backends/hostmem-epc.c
> index ab20b182331..e1c784249ff 100644
> --- a/backends/hostmem-epc.c
> +++ b/backends/hostmem-epc.c
> @@ -24,11 +24,6 @@ sgx_epc_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>       uint32_t ram_flags;
>       int fd;
>   
> -    if (!backend->size) {
> -        error_setg(errp, "can't create backend with size 0");
> -        return false;
> -    }
> -
>       fd = qemu_open("/dev/sgx_vepc", O_RDWR, errp);
>       if (fd < 0) {
>           return false;
> diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
> index 6ad9cad0320..08d0382d76f 100644
> --- a/backends/hostmem-file.c
> +++ b/backends/hostmem-file.c
> @@ -48,10 +48,6 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>       g_autofree gchar *name = NULL;
>       uint32_t ram_flags;
>   
> -    if (!backend->size) {
> -        error_setg(errp, "can't create backend with size 0");
> -        return false;
> -    }
>       if (!fb->mem_path) {
>           error_setg(errp, "mem-path property not set");
>           return false;
> diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
> index 46489212a23..11d456e3ebd 100644
> --- a/backends/hostmem-memfd.c
> +++ b/backends/hostmem-memfd.c
> @@ -49,11 +49,6 @@ memfd_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>       int fd = cpr_find_fd(name, 0);
>       uint32_t ram_flags;
>   
> -    if (!backend->size) {
> -        error_setg(errp, "can't create backend with size 0");
> -        return false;
> -    }
> -
>       if (fd >= 0) {
>           goto have_fd;
>       }
> diff --git a/backends/hostmem-ram.c b/backends/hostmem-ram.c
> index 6a507fad77c..0ae7b4ae759 100644
> --- a/backends/hostmem-ram.c
> +++ b/backends/hostmem-ram.c
> @@ -22,11 +22,6 @@ ram_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>       g_autofree char *name = NULL;
>       uint32_t ram_flags;
>   
> -    if (!backend->size) {
> -        error_setg(errp, "can't create backend with size 0");
> -        return false;
> -    }
> -
>       name = host_memory_backend_get_name(backend);
>       ram_flags = backend->share ? RAM_SHARED : RAM_PRIVATE;
>       ram_flags |= backend->reserve ? 0 : RAM_NORESERVE;
> diff --git a/backends/hostmem-shm.c b/backends/hostmem-shm.c
> index adf60957c3c..0a01c760551 100644
> --- a/backends/hostmem-shm.c
> +++ b/backends/hostmem-shm.c
> @@ -30,11 +30,6 @@ shm_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>       uint32_t ram_flags;
>       int fd = cpr_find_fd(backend_name, 0);
>   
> -    if (!backend->size) {
> -        error_setg(errp, "can't create shm backend with size 0");
> -        return false;
> -    }
> -
>       if (!backend->share) {
>           error_setg(errp, "can't create shm backend with `share=off`");
>           return false;

Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>


ATB,

Mark.

[PATCH 2/7] backends/hostmem-file: Drop useless validation of property "mem-path"

[Markus Armbruster]

A non-optional string property like "mem-path" cannot be null.  Drop
the useless check.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 backends/hostmem-file.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index 08d0382d76f..1e8f8ae6aa8 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -48,11 +48,6 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
     g_autofree gchar *name = NULL;
     uint32_t ram_flags;
 
-    if (!fb->mem_path) {
-        error_setg(errp, "mem-path property not set");
-        return false;
-    }
-
     switch (fb->rom) {
     case ON_OFF_AUTO_AUTO:
         /* Traditionally, opening the file readonly always resulted in ROM. */
-- 
2.55.0

Re: [PATCH 2/7] backends/hostmem-file: Drop useless validation of property "mem-path"

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 01:23:37PM +0100, Markus Armbruster wrote:
> A non-optional string property like "mem-path" cannot be null.  Drop
> the useless check.
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>  backends/hostmem-file.c | 5 -----
>  1 file changed, 5 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 2/7] backends/hostmem-file: Drop useless validation of property "mem-path"

[Mark Cave-Ayland]

On 11/11/2026 12:23, Markus Armbruster wrote:

> A non-optional string property like "mem-path" cannot be null.  Drop
> the useless check.
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>   backends/hostmem-file.c | 5 -----
>   1 file changed, 5 deletions(-)
> 
> diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
> index 08d0382d76f..1e8f8ae6aa8 100644
> --- a/backends/hostmem-file.c
> +++ b/backends/hostmem-file.c
> @@ -48,11 +48,6 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>       g_autofree gchar *name = NULL;
>       uint32_t ram_flags;
>   
> -    if (!fb->mem_path) {
> -        error_setg(errp, "mem-path property not set");
> -        return false;
> -    }
> -
>       switch (fb->rom) {
>       case ON_OFF_AUTO_AUTO:
>           /* Traditionally, opening the file readonly always resulted in ROM. */

Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>


ATB,

Mark.

[PATCH 3/7] backends/hostmem: Improve error reporting when method alloc() fails

[Markus Armbruster]

When HostMemoryBackend method alloc() fails, the error report isn't
always clear.  E.g. "-object memory-backend-shm,id=mem0,size=1E" fails
for me like this:

    qemu-system-x86_64: unable to map backing store for guest RAM: Cannot allocate memory

Leaves users guessing which part of the (often lengthy) command line
needs fixing.

Let's prepend a bit of context:

    qemu-system-x86_64: can't create memory-backend-shm: unable to map backing store for guest RAM: Cannot allocate memory

This makes an error message in shm_backend_memory_alloc() partly
redundant:

    qemu-system-x86_64: can't create memory-backend-shm: can't create shm backend with `share=off`

Change it to

    qemu-system-x86_64: can't create memory-backend-shm: backend requires 'share=on'

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 backends/hostmem-shm.c | 2 +-
 backends/hostmem.c     | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/backends/hostmem-shm.c b/backends/hostmem-shm.c
index 0a01c760551..d1cba22cbeb 100644
--- a/backends/hostmem-shm.c
+++ b/backends/hostmem-shm.c
@@ -31,7 +31,7 @@ shm_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
     int fd = cpr_find_fd(backend_name, 0);
 
     if (!backend->share) {
-        error_setg(errp, "can't create shm backend with `share=off`");
+        error_setg(errp, "backend requires 'share=on'");
         return false;
     }
 
diff --git a/backends/hostmem.c b/backends/hostmem.c
index 173d042be35..1c2a5d42fc5 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -335,6 +335,7 @@ size_t host_memory_backend_pagesize(HostMemoryBackend *memdev)
 static void
 host_memory_backend_memory_complete(UserCreatable *uc, Error **errp)
 {
+    ERRP_GUARD();
     HostMemoryBackend *backend = MEMORY_BACKEND(uc);
     HostMemoryBackendClass *bc = MEMORY_BACKEND_GET_CLASS(uc);
     void *ptr;
@@ -346,6 +347,8 @@ host_memory_backend_memory_complete(UserCreatable *uc, Error **errp)
         return;
     }
     if (!bc->alloc(backend, errp)) {
+        error_prepend(errp, "can't create '%s': ",
+                      object_get_typename(OBJECT(uc)));
         return;
     }
 
-- 
2.55.0

Re: [PATCH 3/7] backends/hostmem: Improve error reporting when method alloc() fails

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 01:23:38PM +0100, Markus Armbruster wrote:
> When HostMemoryBackend method alloc() fails, the error report isn't
> always clear.  E.g. "-object memory-backend-shm,id=mem0,size=1E" fails
> for me like this:
> 
>     qemu-system-x86_64: unable to map backing store for guest RAM: Cannot allocate memory
> 
> Leaves users guessing which part of the (often lengthy) command line
> needs fixing.
> 
> Let's prepend a bit of context:
> 
>     qemu-system-x86_64: can't create memory-backend-shm: unable to map backing store for guest RAM: Cannot allocate memory
> 
> This makes an error message in shm_backend_memory_alloc() partly
> redundant:
> 
>     qemu-system-x86_64: can't create memory-backend-shm: can't create shm backend with `share=off`
> 
> Change it to
> 
>     qemu-system-x86_64: can't create memory-backend-shm: backend requires 'share=on'
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>  backends/hostmem-shm.c | 2 +-
>  backends/hostmem.c     | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 3/7] backends/hostmem: Improve error reporting when method alloc() fails

[Mark Cave-Ayland]

On 11/11/2026 12:23, Markus Armbruster wrote:

> When HostMemoryBackend method alloc() fails, the error report isn't
> always clear.  E.g. "-object memory-backend-shm,id=mem0,size=1E" fails
> for me like this:
> 
>      qemu-system-x86_64: unable to map backing store for guest RAM: Cannot allocate memory
> 
> Leaves users guessing which part of the (often lengthy) command line
> needs fixing.
> 
> Let's prepend a bit of context:
> 
>      qemu-system-x86_64: can't create memory-backend-shm: unable to map backing store for guest RAM: Cannot allocate memory
> 
> This makes an error message in shm_backend_memory_alloc() partly
> redundant:
> 
>      qemu-system-x86_64: can't create memory-backend-shm: can't create shm backend with `share=off`
> 
> Change it to
> 
>      qemu-system-x86_64: can't create memory-backend-shm: backend requires 'share=on'
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>   backends/hostmem-shm.c | 2 +-
>   backends/hostmem.c     | 3 +++
>   2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/backends/hostmem-shm.c b/backends/hostmem-shm.c
> index 0a01c760551..d1cba22cbeb 100644
> --- a/backends/hostmem-shm.c
> +++ b/backends/hostmem-shm.c
> @@ -31,7 +31,7 @@ shm_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>       int fd = cpr_find_fd(backend_name, 0);
>   
>       if (!backend->share) {
> -        error_setg(errp, "can't create shm backend with `share=off`");
> +        error_setg(errp, "backend requires 'share=on'");
>           return false;
>       }
>   
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index 173d042be35..1c2a5d42fc5 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -335,6 +335,7 @@ size_t host_memory_backend_pagesize(HostMemoryBackend *memdev)
>   static void
>   host_memory_backend_memory_complete(UserCreatable *uc, Error **errp)
>   {
> +    ERRP_GUARD();
>       HostMemoryBackend *backend = MEMORY_BACKEND(uc);
>       HostMemoryBackendClass *bc = MEMORY_BACKEND_GET_CLASS(uc);
>       void *ptr;
> @@ -346,6 +347,8 @@ host_memory_backend_memory_complete(UserCreatable *uc, Error **errp)
>           return;
>       }
>       if (!bc->alloc(backend, errp)) {
> +        error_prepend(errp, "can't create '%s': ",
> +                      object_get_typename(OBJECT(uc)));
>           return;
>       } 

Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>


ATB,

Mark.

[PATCH 4/7] backends/hostmem-epc: Register QOM type unconditionally

[Markus Armbruster]

The example from docs/system/i386/sgx.rst section "Launching a guest"
fails for me like this:

    $ qemu-system-x86_64 -cpu host,+sgx-provisionkey -object memory-backend-epc,id=mem1,size=64M,prealloc=on -M sgx-epc.0.memdev=mem1,sgx-epc.0.node=0
    qemu-system-x86_64: invalid object type: memory-backend-epc

Device "sgx-epc" has a link property to a "memory-backend-epc" (SgxEPC
member memdev).  It's not optional, so we must create a
"memory-backend-epc" to be able to create an "sgx-epc".  In the test
shown above, "sgx-epc" exists, but "memory-backend-epc" does not.

The latter doesn't exist for me, because we register QOM type
"memory-backend-epc" only when we can open /dev/sgx_vepc read/write,
which fails for me.  Such conditional registration is unusual and
problematic:

1. Management applications use introspection interfaces to find out
what a certain QEMU can do.  Conditional type registration makes QOM
introspection results depend on the condition, which generally makes
them valid only for the process that produced them.  Undesirable.

2. For user-creatable objects like "memory-backend-epc", it also makes
QAPI introspection unreliable: query-qmp-schema claims the type
exists (object-add argument @qom-type accepts "memory-backend-epc")
even when it doesn't.

Conditional registration actually serves no purpose here, because we
still have to open /dev/sgx_vepc for real when we create the object,
and need and do handle errors then.

Register unconditionally.  The example now fails to create the object,
like this:

    qemu-system-x86_64: can't create 'memory-backend-epc': Could not open '/dev/sgx_vepc': No such file or directory

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 backends/hostmem-epc.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/backends/hostmem-epc.c b/backends/hostmem-epc.c
index e1c784249ff..bf5aecdfd45 100644
--- a/backends/hostmem-epc.c
+++ b/backends/hostmem-epc.c
@@ -62,12 +62,7 @@ static const TypeInfo sgx_epc_backed_info = {
 
 static void register_types(void)
 {
-    int fd = qemu_open_old("/dev/sgx_vepc", O_RDWR);
-    if (fd >= 0) {
-        close(fd);
-
-        type_register_static(&sgx_epc_backed_info);
-    }
+    type_register_static(&sgx_epc_backed_info);
 }
 
 type_init(register_types);
-- 
2.55.0

Re: [PATCH 4/7] backends/hostmem-epc: Register QOM type unconditionally

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 01:23:39PM +0100, Markus Armbruster wrote:
> The example from docs/system/i386/sgx.rst section "Launching a guest"
> fails for me like this:
> 
>     $ qemu-system-x86_64 -cpu host,+sgx-provisionkey -object memory-backend-epc,id=mem1,size=64M,prealloc=on -M sgx-epc.0.memdev=mem1,sgx-epc.0.node=0
>     qemu-system-x86_64: invalid object type: memory-backend-epc
> 
> Device "sgx-epc" has a link property to a "memory-backend-epc" (SgxEPC
> member memdev).  It's not optional, so we must create a
> "memory-backend-epc" to be able to create an "sgx-epc".  In the test
> shown above, "sgx-epc" exists, but "memory-backend-epc" does not.
> 
> The latter doesn't exist for me, because we register QOM type
> "memory-backend-epc" only when we can open /dev/sgx_vepc read/write,
> which fails for me.  Such conditional registration is unusual and
> problematic:
> 
> 1. Management applications use introspection interfaces to find out
> what a certain QEMU can do.  Conditional type registration makes QOM
> introspection results depend on the condition, which generally makes
> them valid only for the process that produced them.  Undesirable.
> 
> 2. For user-creatable objects like "memory-backend-epc", it also makes
> QAPI introspection unreliable: query-qmp-schema claims the type
> exists (object-add argument @qom-type accepts "memory-backend-epc")
> even when it doesn't.
> 
> Conditional registration actually serves no purpose here, because we
> still have to open /dev/sgx_vepc for real when we create the object,
> and need and do handle errors then.
> 
> Register unconditionally.  The example now fails to create the object,
> like this:
> 
>     qemu-system-x86_64: can't create 'memory-backend-epc': Could not open '/dev/sgx_vepc': No such file or directory

Bonus points - this error message is orders of magnitude
more useful to users than

  qemu-system-x86_64: invalid object type: memory-backend-epc

which makes them think their QEMU is built wrong or outdated.

> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>  backends/hostmem-epc.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

> 
> diff --git a/backends/hostmem-epc.c b/backends/hostmem-epc.c
> index e1c784249ff..bf5aecdfd45 100644
> --- a/backends/hostmem-epc.c
> +++ b/backends/hostmem-epc.c
> @@ -62,12 +62,7 @@ static const TypeInfo sgx_epc_backed_info = {
>  
>  static void register_types(void)
>  {
> -    int fd = qemu_open_old("/dev/sgx_vepc", O_RDWR);
> -    if (fd >= 0) {
> -        close(fd);
> -
> -        type_register_static(&sgx_epc_backed_info);
> -    }
> +    type_register_static(&sgx_epc_backed_info);
>  }
>  
>  type_init(register_types);
> -- 
> 2.55.0
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 4/7] backends/hostmem-epc: Register QOM type unconditionally

[Mark Cave-Ayland]

On 11/11/2026 12:23, Markus Armbruster wrote:

> The example from docs/system/i386/sgx.rst section "Launching a guest"
> fails for me like this:
> 
>      $ qemu-system-x86_64 -cpu host,+sgx-provisionkey -object memory-backend-epc,id=mem1,size=64M,prealloc=on -M sgx-epc.0.memdev=mem1,sgx-epc.0.node=0
>      qemu-system-x86_64: invalid object type: memory-backend-epc
> 
> Device "sgx-epc" has a link property to a "memory-backend-epc" (SgxEPC
> member memdev).  It's not optional, so we must create a
> "memory-backend-epc" to be able to create an "sgx-epc".  In the test
> shown above, "sgx-epc" exists, but "memory-backend-epc" does not.
> 
> The latter doesn't exist for me, because we register QOM type
> "memory-backend-epc" only when we can open /dev/sgx_vepc read/write,
> which fails for me.  Such conditional registration is unusual and
> problematic:
> 
> 1. Management applications use introspection interfaces to find out
> what a certain QEMU can do.  Conditional type registration makes QOM
> introspection results depend on the condition, which generally makes
> them valid only for the process that produced them.  Undesirable.
> 
> 2. For user-creatable objects like "memory-backend-epc", it also makes
> QAPI introspection unreliable: query-qmp-schema claims the type
> exists (object-add argument @qom-type accepts "memory-backend-epc")
> even when it doesn't.
> 
> Conditional registration actually serves no purpose here, because we
> still have to open /dev/sgx_vepc for real when we create the object,
> and need and do handle errors then.
> 
> Register unconditionally.  The example now fails to create the object,
> like this:
> 
>      qemu-system-x86_64: can't create 'memory-backend-epc': Could not open '/dev/sgx_vepc': No such file or directory
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>   backends/hostmem-epc.c | 7 +------
>   1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/backends/hostmem-epc.c b/backends/hostmem-epc.c
> index e1c784249ff..bf5aecdfd45 100644
> --- a/backends/hostmem-epc.c
> +++ b/backends/hostmem-epc.c
> @@ -62,12 +62,7 @@ static const TypeInfo sgx_epc_backed_info = {
>   
>   static void register_types(void)
>   {
> -    int fd = qemu_open_old("/dev/sgx_vepc", O_RDWR);
> -    if (fd >= 0) {
> -        close(fd);
> -
> -        type_register_static(&sgx_epc_backed_info);
> -    }
> +    type_register_static(&sgx_epc_backed_info);
>   }
>   
>   type_init(register_types);

Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>


ATB,

Mark.

[PATCH 5/7] backends/hostmem-memfd: Register QOM type unconditionally

[Markus Armbruster]

We register QOM type "memory-backend-memfd" only when a test of
memfd_create() succeeds.  Such conditional registration is unusual and
problematic:

1. Management applications use introspection interfaces to find out
what a certain QEMU can do.  Conditional type registration makes QOM
introspection results depend on the condition, which generally makes
them valid only for the process that produced them.  Undesirable.

2. For user-creatable objects like "memory-backend-memfd", it also
makes QAPI introspection unreliable: query-qmp-schema claims the type
exists (object-add argument @qom-type accepts "memory-backend-memfd")
even when it doesn't.

Conditional registration actually serves no purpose here, because we
still have to memfd_create() for real when we create the object, and
need and do handle errors then.

Register the type unconditionally.

To test, I hacked the qemu_memfd() call to fail.  The error for
-object memory-backend-memfd,id=mem0,size=1m changes from

    qemu-system-x86_64: invalid object type: memory-backend-memfd

to

    qemu-system-x86_64: can't create 'memory-backend-memfd': failed to create memfd with flags 0x3: Invalid argument

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 backends/hostmem-memfd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
index 11d456e3ebd..54f84ae331a 100644
--- a/backends/hostmem-memfd.c
+++ b/backends/hostmem-memfd.c
@@ -223,9 +223,7 @@ static const TypeInfo memfd_backend_info = {
 
 static void register_types(void)
 {
-    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
-        type_register_static(&memfd_backend_info);
-    }
+    type_register_static(&memfd_backend_info);
 }
 
 type_init(register_types);
-- 
2.55.0

Re: [PATCH 5/7] backends/hostmem-memfd: Register QOM type unconditionally

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 01:23:40PM +0100, Markus Armbruster wrote:
> We register QOM type "memory-backend-memfd" only when a test of
> memfd_create() succeeds.  Such conditional registration is unusual and
> problematic:
> 
> 1. Management applications use introspection interfaces to find out
> what a certain QEMU can do.  Conditional type registration makes QOM
> introspection results depend on the condition, which generally makes
> them valid only for the process that produced them.  Undesirable.
> 
> 2. For user-creatable objects like "memory-backend-memfd", it also
> makes QAPI introspection unreliable: query-qmp-schema claims the type
> exists (object-add argument @qom-type accepts "memory-backend-memfd")
> even when it doesn't.
> 
> Conditional registration actually serves no purpose here, because we
> still have to memfd_create() for real when we create the object, and
> need and do handle errors then.
> 
> Register the type unconditionally.
> 
> To test, I hacked the qemu_memfd() call to fail.  The error for
> -object memory-backend-memfd,id=mem0,size=1m changes from
> 
>     qemu-system-x86_64: invalid object type: memory-backend-memfd
> 
> to
> 
>     qemu-system-x86_64: can't create 'memory-backend-memfd': failed to create memfd with flags 0x3: Invalid argument
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>  backends/hostmem-memfd.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 5/7] backends/hostmem-memfd: Register QOM type unconditionally

[Mark Cave-Ayland]

On 11/11/2026 12:23, Markus Armbruster wrote:

> We register QOM type "memory-backend-memfd" only when a test of
> memfd_create() succeeds.  Such conditional registration is unusual and
> problematic:
> 
> 1. Management applications use introspection interfaces to find out
> what a certain QEMU can do.  Conditional type registration makes QOM
> introspection results depend on the condition, which generally makes
> them valid only for the process that produced them.  Undesirable.
> 
> 2. For user-creatable objects like "memory-backend-memfd", it also
> makes QAPI introspection unreliable: query-qmp-schema claims the type
> exists (object-add argument @qom-type accepts "memory-backend-memfd")
> even when it doesn't.
> 
> Conditional registration actually serves no purpose here, because we
> still have to memfd_create() for real when we create the object, and
> need and do handle errors then.
> 
> Register the type unconditionally.
> 
> To test, I hacked the qemu_memfd() call to fail.  The error for
> -object memory-backend-memfd,id=mem0,size=1m changes from
> 
>      qemu-system-x86_64: invalid object type: memory-backend-memfd
> 
> to
> 
>      qemu-system-x86_64: can't create 'memory-backend-memfd': failed to create memfd with flags 0x3: Invalid argument
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>   backends/hostmem-memfd.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
> index 11d456e3ebd..54f84ae331a 100644
> --- a/backends/hostmem-memfd.c
> +++ b/backends/hostmem-memfd.c
> @@ -223,9 +223,7 @@ static const TypeInfo memfd_backend_info = {
>   
>   static void register_types(void)
>   {
> -    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
> -        type_register_static(&memfd_backend_info);
> -    }
> +    type_register_static(&memfd_backend_info);
>   }
>   
>   type_init(register_types);

Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>


ATB,

Mark.

[PATCH 6/7] util/memfd: Improve error message when memfd_create() fails

[Markus Armbruster]

qemu_memfd_create() reports something like

    failed to create memfd with flags 0x3: Invalid argument

when memfd_create() fails.  To make sense of this, you have to
understand what flags are, and how to decode them.

qemu_memfd_create() computes the flags from @seals and @hugetlb, so
show these instead, like this:

    failed to create memfd with sealing and without huge pages: Invalid argument

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 util/memfd.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/util/memfd.c b/util/memfd.c
index 07beab174dc..a398b246600 100644
--- a/util/memfd.c
+++ b/util/memfd.c
@@ -73,7 +73,10 @@ int qemu_memfd_create(const char *name, size_t size, bool hugetlb,
     mfd = memfd_create(name, flags);
     if (mfd < 0) {
         error_setg_errno(errp, errno,
-                         "failed to create memfd with flags 0x%x", flags);
+                         "failed to create memfd %s sealing"
+                         " and %s huge pages",
+                         seals ? "with" : "without",
+                         hugetlb ? "with" : "without");
         goto err;
     }
 
-- 
2.55.0

Re: [PATCH 6/7] util/memfd: Improve error message when memfd_create() fails

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 01:23:41PM +0100, Markus Armbruster wrote:
> qemu_memfd_create() reports something like
> 
>     failed to create memfd with flags 0x3: Invalid argument
> 
> when memfd_create() fails.  To make sense of this, you have to
> understand what flags are, and how to decode them.
> 
> qemu_memfd_create() computes the flags from @seals and @hugetlb, so
> show these instead, like this:
> 
>     failed to create memfd with sealing and without huge pages: Invalid argument
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>  util/memfd.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 6/7] util/memfd: Improve error message when memfd_create() fails

[Mark Cave-Ayland]

On 11/11/2026 12:23, Markus Armbruster wrote:

> qemu_memfd_create() reports something like
> 
>      failed to create memfd with flags 0x3: Invalid argument
> 
> when memfd_create() fails.  To make sense of this, you have to
> understand what flags are, and how to decode them.
> 
> qemu_memfd_create() computes the flags from @seals and @hugetlb, so
> show these instead, like this:
> 
>      failed to create memfd with sealing and without huge pages: Invalid argument
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>   util/memfd.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/util/memfd.c b/util/memfd.c
> index 07beab174dc..a398b246600 100644
> --- a/util/memfd.c
> +++ b/util/memfd.c
> @@ -73,7 +73,10 @@ int qemu_memfd_create(const char *name, size_t size, bool hugetlb,
>       mfd = memfd_create(name, flags);
>       if (mfd < 0) {
>           error_setg_errno(errp, errno,
> -                         "failed to create memfd with flags 0x%x", flags);
> +                         "failed to create memfd %s sealing"
> +                         " and %s huge pages",
> +                         seals ? "with" : "without",
> +                         hugetlb ? "with" : "without");
>           goto err;
>       }

Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>


ATB,

Mark.

[PATCH 7/7] backends/hostmem-memfd: Add huge TLB properties unconditionally

[Markus Armbruster]

We add class properties "hugetlb" and "hugetlbsize" only when a test
of memfd_create() succeeds.  Such conditional registration is unusual
and can be problematic:

1. Management applications use introspection interfaces to find out
what a certain QEMU can do.  Conditional property addition makes QOM
introspection results depend on the condition, which generally makes
them valid only for the process that produced them.  Undesirable.

2. For user-creatable objects like "memory-backend-memfd", it also
makes QAPI introspection unreliable: query-qmp-schema claims the
properties exist (object-add takes arguments @hugetlb and @hugetlbsize
when argument @qom-type is "memory-backend-memfd") even when it
doesn't.

Conditional registration actually serves no purpose here, because we
still have to memfd_create() for real when we create the object, and
need and do handle errors then.

Moreover, we actually KVM ioctl KVM_CREATE_GUEST_MEMFD instead of
memfd_create() there when @guest-memfd is on.  If the memfd_create()
check can fail when the ioctl could still succeed, the condition is
counter-productive.

Add the properties unconditionally.

To test, I hacked the qemu_memfd() call to fail.  The error for
-object memory-backend-memfd,id=mem0,size=1m,hugetlb=off,hugetlbsize=512,seal=on
changes from

    qemu-system-x86_64: Property 'memory-backend-memfd.hugetlbsize' not found

to

    qemu-system-x86_64: can't create 'memory-backend-memfd': failed to create memfd with sealing and without huge pages: Invalid argument

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 backends/hostmem-memfd.c | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
index 54f84ae331a..b945fc46021 100644
--- a/backends/hostmem-memfd.c
+++ b/backends/hostmem-memfd.c
@@ -184,20 +184,18 @@ memfd_backend_class_init(ObjectClass *oc, const void *data)
 
     bc->alloc = memfd_backend_memory_alloc;
 
-    if (qemu_memfd_check(MFD_HUGETLB)) {
-        object_class_property_add_bool(oc, "hugetlb",
-                                       memfd_backend_get_hugetlb,
-                                       memfd_backend_set_hugetlb);
-        object_class_property_set_description(oc, "hugetlb",
-                                              "Use huge pages");
-        object_class_property_add(oc, "hugetlbsize", "uint64",
-                                  &uint64_type_info,
-                                  memfd_backend_get_hugetlbsize,
-                                  memfd_backend_set_hugetlbsize,
-                                  NULL, NULL);
-        object_class_property_set_description(oc, "hugetlbsize",
-                                              "Huge pages size (ex: 2M, 1G)");
-    }
+    object_class_property_add_bool(oc, "hugetlb",
+                                   memfd_backend_get_hugetlb,
+                                   memfd_backend_set_hugetlb);
+    object_class_property_set_description(oc, "hugetlb",
+                                          "Use huge pages");
+    object_class_property_add(oc, "hugetlbsize", "uint64",
+                              &uint64_type_info,
+                              memfd_backend_get_hugetlbsize,
+                              memfd_backend_set_hugetlbsize,
+                              NULL, NULL);
+    object_class_property_set_description(oc, "hugetlbsize",
+                                          "Huge pages size (ex: 2M, 1G)");
 
     object_class_property_add_enum(oc, "guest-memfd", "OnOffAuto",
                                    &OnOffAuto_type_info,
-- 
2.55.0

Re: [PATCH 7/7] backends/hostmem-memfd: Add huge TLB properties unconditionally

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 01:23:42PM +0100, Markus Armbruster wrote:
> We add class properties "hugetlb" and "hugetlbsize" only when a test
> of memfd_create() succeeds.  Such conditional registration is unusual
> and can be problematic:
> 
> 1. Management applications use introspection interfaces to find out
> what a certain QEMU can do.  Conditional property addition makes QOM
> introspection results depend on the condition, which generally makes
> them valid only for the process that produced them.  Undesirable.
> 
> 2. For user-creatable objects like "memory-backend-memfd", it also
> makes QAPI introspection unreliable: query-qmp-schema claims the
> properties exist (object-add takes arguments @hugetlb and @hugetlbsize
> when argument @qom-type is "memory-backend-memfd") even when it
> doesn't.
> 
> Conditional registration actually serves no purpose here, because we
> still have to memfd_create() for real when we create the object, and
> need and do handle errors then.
> 
> Moreover, we actually KVM ioctl KVM_CREATE_GUEST_MEMFD instead of
> memfd_create() there when @guest-memfd is on.  If the memfd_create()
> check can fail when the ioctl could still succeed, the condition is
> counter-productive.
> 
> Add the properties unconditionally.
> 
> To test, I hacked the qemu_memfd() call to fail.  The error for
> -object memory-backend-memfd,id=mem0,size=1m,hugetlb=off,hugetlbsize=512,seal=on
> changes from
> 
>     qemu-system-x86_64: Property 'memory-backend-memfd.hugetlbsize' not found
> 
> to
> 
>     qemu-system-x86_64: can't create 'memory-backend-memfd': failed to create memfd with sealing and without huge pages: Invalid argument
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>  backends/hostmem-memfd.c | 26 ++++++++++++--------------
>  1 file changed, 12 insertions(+), 14 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 7/7] backends/hostmem-memfd: Add huge TLB properties unconditionally

[Mark Cave-Ayland]

On 11/11/2026 12:23, Markus Armbruster wrote:

> We add class properties "hugetlb" and "hugetlbsize" only when a test
> of memfd_create() succeeds.  Such conditional registration is unusual
> and can be problematic:
> 
> 1. Management applications use introspection interfaces to find out
> what a certain QEMU can do.  Conditional property addition makes QOM
> introspection results depend on the condition, which generally makes
> them valid only for the process that produced them.  Undesirable.
> 
> 2. For user-creatable objects like "memory-backend-memfd", it also
> makes QAPI introspection unreliable: query-qmp-schema claims the
> properties exist (object-add takes arguments @hugetlb and @hugetlbsize
> when argument @qom-type is "memory-backend-memfd") even when it
> doesn't.
> 
> Conditional registration actually serves no purpose here, because we
> still have to memfd_create() for real when we create the object, and
> need and do handle errors then.
> 
> Moreover, we actually KVM ioctl KVM_CREATE_GUEST_MEMFD instead of
> memfd_create() there when @guest-memfd is on.  If the memfd_create()
> check can fail when the ioctl could still succeed, the condition is
> counter-productive.
> 
> Add the properties unconditionally.
> 
> To test, I hacked the qemu_memfd() call to fail.  The error for
> -object memory-backend-memfd,id=mem0,size=1m,hugetlb=off,hugetlbsize=512,seal=on
> changes from
> 
>      qemu-system-x86_64: Property 'memory-backend-memfd.hugetlbsize' not found
> 
> to
> 
>      qemu-system-x86_64: can't create 'memory-backend-memfd': failed to create memfd with sealing and without huge pages: Invalid argument
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
>   backends/hostmem-memfd.c | 26 ++++++++++++--------------
>   1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
> index 54f84ae331a..b945fc46021 100644
> --- a/backends/hostmem-memfd.c
> +++ b/backends/hostmem-memfd.c
> @@ -184,20 +184,18 @@ memfd_backend_class_init(ObjectClass *oc, const void *data)
>   
>       bc->alloc = memfd_backend_memory_alloc;
>   
> -    if (qemu_memfd_check(MFD_HUGETLB)) {
> -        object_class_property_add_bool(oc, "hugetlb",
> -                                       memfd_backend_get_hugetlb,
> -                                       memfd_backend_set_hugetlb);
> -        object_class_property_set_description(oc, "hugetlb",
> -                                              "Use huge pages");
> -        object_class_property_add(oc, "hugetlbsize", "uint64",
> -                                  &uint64_type_info,
> -                                  memfd_backend_get_hugetlbsize,
> -                                  memfd_backend_set_hugetlbsize,
> -                                  NULL, NULL);
> -        object_class_property_set_description(oc, "hugetlbsize",
> -                                              "Huge pages size (ex: 2M, 1G)");
> -    }
> +    object_class_property_add_bool(oc, "hugetlb",
> +                                   memfd_backend_get_hugetlb,
> +                                   memfd_backend_set_hugetlb);
> +    object_class_property_set_description(oc, "hugetlb",
> +                                          "Use huge pages");
> +    object_class_property_add(oc, "hugetlbsize", "uint64",
> +                              &uint64_type_info,
> +                              memfd_backend_get_hugetlbsize,
> +                              memfd_backend_set_hugetlbsize,
> +                              NULL, NULL);
> +    object_class_property_set_description(oc, "hugetlbsize",
> +                                          "Huge pages size (ex: 2M, 1G)");
>   
>       object_class_property_add_enum(oc, "guest-memfd", "OnOffAuto",
>                                      &OnOffAuto_type_info,

Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>


ATB,

Mark.

Use of qemu_memfd_check() in system/physmem.c (was: [PATCH 0/7] backends/hostmem: Make QOM types and properties unconditional)

[Markus Armbruster]

After this series, there is just one use of qemu_memfd_check() outside
tests/ left:

    /*
     * Create MAP_SHARED RAMBlocks by mmap'ing a file descriptor, so it can be
     * shared with another process if CPR is being used.  Use memfd if available
     * because it has no size limits, else use POSIX shm.
     */
    static int qemu_ram_get_shared_fd(const char *name, bool *reused, Error **errp)
    {
        int fd = cpr_find_fd(name, 0);

        if (fd >= 0) {
            *reused = true;
            return fd;
        }

--->    if (qemu_memfd_check(0)) {
            fd = qemu_memfd_create(name, 0, 0, 0, 0, errp);
        } else {
            fd = qemu_shm_alloc(0, errp);
        }

        if (fd >= 0 && !cpr_save_fd(name, 0, fd, errp)) {
            close(fd);
            fd = -1;
        }
        *reused = false;
        return fd;
    }

We test whether memfd_create("test", MFD_CLOEXEC) succeeds to decide
whether to use memfd_create(name, MFD_CLOEXEC) or POSIX shared memory.
This is anti-pattern "predict which method should succed, then try that
method".  A better way is "try methods one after the other until one
succeeds".

Doing that here would require refactoring, because both
qemu_memfd_create() and qemu_shm_alloc() do additional work that can
also fail: ftruncate().

Doubt: qemu_memfd_create(0) caches its result[*].  Is that a mere
optimization, or does something depend on "we use the same method
always"?

I don't plan to mess with this myself, I'm merely reporting something I
found.


[*] Only when the argument is 0.