qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Markus Armbruster]

My build of qemu-system-x86_64 has device sgx-epc:

 --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
 <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}

The device as a link property to a memory-backend-epc:

 --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
 <-- {"return": [...
                 {"name": "memdev", "type": "link<memory-backend-epc>"},
                 ...]}

However, type memory-backend-epc does not exist:

 --> {"execute": "qom-list-types", "arguments": {"implements": "memory-backend"}}
 <-- {"return": [{"name": "memory-backend-ram", "parent": "memory-backend"}, {"name": "memory-backend-file", "parent": "memory-backend"}, {"name": "memory-backend-memfd", "parent": "memory-backend"}, {"name": "memory-backend-shm", "parent": "memory-backend"}]}

The example from docs/system/i386/sgx.rst

    Launching a guest
    -----------------

    To launch a SGX guest:

    .. parsed-literal::

      |qemu_system_x86| \\
       -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

does not work:

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

CONFIG_SGX is enabled in my build:

    $ find bld-x86 -name \*.h -exec grep CONFIG_SGX {} +
    bld-x86/x86_64-softmmu-config-devices.h:#define CONFIG_SGX 1
    bld-x86/config-poison.h:#pragma GCC poison CONFIG_SGX

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Daniel P. Berrangé]

On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
> My build of qemu-system-x86_64 has device sgx-epc:
> 
>  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
>  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
> 
> The device as a link property to a memory-backend-epc:
> 
>  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
>  <-- {"return": [...
>                  {"name": "memdev", "type": "link<memory-backend-epc>"},
>                  ...]}
> 
> However, type memory-backend-epc does not exist:
> 
>  --> {"execute": "qom-list-types", "arguments": {"implements": "memory-backend"}}
>  <-- {"return": [{"name": "memory-backend-ram", "parent": "memory-backend"}, {"name": "memory-backend-file", "parent": "memory-backend"}, {"name": "memory-backend-memfd", "parent": "memory-backend"}, {"name": "memory-backend-shm", "parent": "memory-backend"}]}

There is some rather dubious code that conditionally registers
the type

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);
    }
}


Normal practice is for types to be unconditionally registered.  Do we
have any examples outside of this SGX case where we conditionally
register types ?   Should we change this to follow normal practice ?

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: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Peter Maydell]

On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
> > My build of qemu-system-x86_64 has device sgx-epc:
> >
> >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
> >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
> >
> > The device as a link property to a memory-backend-epc:
> >
> >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
> >  <-- {"return": [...
> >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
> >                  ...]}
> >
> > However, type memory-backend-epc does not exist:

> There is some rather dubious code that conditionally registers
> the type
>
> 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);
>     }
> }
>
>
> Normal practice is for types to be unconditionally registered.  Do we
> have any examples outside of this SGX case where we conditionally
> register types ?   Should we change this to follow normal practice ?

TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
"calls to type_register not indented by exactly 4 spaces" and
I think the other cases are "misindented" or "data-driven
type registration" rather than trying to do things conditionally
(but I didn't actually look at all of them, instead making
guesses based on variable names, so maybe there's one or two
more I missed).

I guess maybe this is trying to work around the fact that the
memory backend API doesn't give a backend any place to say
"this is never going to work" early, because instance_init isn't
allowed to fail, these objects aren't TYPE_DEVICE so they
don't have "realize", and so the only other option is
"fail every alloc call" ?

thanks
-- PMM

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Daniel P. Berrangé]

On Fri, Oct 23, 2026 at 11:44:10AM +0100, Peter Maydell wrote:
> On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
> > > My build of qemu-system-x86_64 has device sgx-epc:
> > >
> > >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
> > >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
> > >
> > > The device as a link property to a memory-backend-epc:
> > >
> > >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
> > >  <-- {"return": [...
> > >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
> > >                  ...]}
> > >
> > > However, type memory-backend-epc does not exist:
> 
> > There is some rather dubious code that conditionally registers
> > the type
> >
> > 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);
> >     }
> > }
> >
> >
> > Normal practice is for types to be unconditionally registered.  Do we
> > have any examples outside of this SGX case where we conditionally
> > register types ?   Should we change this to follow normal practice ?
> 
> TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
> "calls to type_register not indented by exactly 4 spaces" and
> I think the other cases are "misindented" or "data-driven
> type registration" rather than trying to do things conditionally
> (but I didn't actually look at all of them, instead making
> guesses based on variable names, so maybe there's one or two
> more I missed).
> 
> I guess maybe this is trying to work around the fact that the
> memory backend API doesn't give a backend any place to say
> "this is never going to work" early, because instance_init isn't
> allowed to fail, these objects aren't TYPE_DEVICE so they
> don't have "realize", and so the only other option is
> "fail every alloc call" ?

The memory backends are all implementing the UserCreatable
interface, which provides a "complete" method where they
could gracefully report lack of the feature via 'errp'.

This is not obvious since UserCreatable is implemented in
the parent base class, but the subclasses could provide
their own  'complete' impl and chain up the parent impl

m
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: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Peter Maydell]

On Fri, 23 Oct 2026 at 12:08, Daniel P. Berrangé <berrange@redhat.com> wrote:
> The memory backends are all implementing the UserCreatable
> interface, which provides a "complete" method where they
> could gracefully report lack of the feature via 'errp'.

I didn't realize UserCreatable was a thing. It seems unfortunate
that we have accumulated three different kinds of object
creation/destruction life cycle:

- instance_init / instance_finalize
- instance_init / realize / unrealize / instance_finalize
- instance_init / complete / prepare_delete / instance_finalize

-- PMM

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Daniel P. Berrangé]

On Fri, Oct 23, 2026 at 12:50:24PM +0100, Peter Maydell wrote:
> On Fri, 23 Oct 2026 at 12:08, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > The memory backends are all implementing the UserCreatable
> > interface, which provides a "complete" method where they
> > could gracefully report lack of the feature via 'errp'.
> 
> I didn't realize UserCreatable was a thing. It seems unfortunate
> that we have accumulated three different kinds of object
> creation/destruction life cycle:
> 
> - instance_init / instance_finalize

This is all stuff that is supposed to be basic self contanied
initialization/cleanup with no side effects or dependencies,
and impossible to fail, which is pretty clear semantics.
During init, no external properties have been set yet, and
during finalize it is already disconnected from the QOM tree.
Essentially these should be basic memory allocs/free, mutex
inits/destroys, setting default int values if non-zero, etc.

> - instance_init / realize / unrealize / instance_finalize
> - instance_init / complete / prepare_delete / instance_finalize

These two have clear overlap in that they both take place after
user specified properties have been set, and deal with types of
initialization/setup/cleanup that can fail and have external
depedencies.

UserCreatable has another aspect in that it is the witness
flag for whether a QOM type is permissible to create using
-object / object_add.

I've periodically wondered if we could make them the same, but
the realize/unrealize phases have significantly more complexity
and dependancies than the complete/prepare_delete and most
notably, 'realize' has a 'bus' parameter.

I think that an approach to unification would end up with the
'Device' class implementing UserCreatable and providing a
'complete' method which in turn called the 'realize' method.
IOW, nothing much would really change in terms of impls, as
all Device subclasses would carry on using realize/unrealize.
It would merely make Device tree available to -object/object_add.
There are probably quite a few edge case problems hiding in
there though if one were to actually try to do this, so the
pragmatic option is really to ignore this all and accept the
different APIs for Device vs non-Device QOM.

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: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Peter Maydell]

On Fri, 23 Oct 2026 at 13:37, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Fri, Oct 23, 2026 at 12:50:24PM +0100, Peter Maydell wrote:
> > On Fri, 23 Oct 2026 at 12:08, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > The memory backends are all implementing the UserCreatable
> > > interface, which provides a "complete" method where they
> > > could gracefully report lack of the feature via 'errp'.
> >
> > I didn't realize UserCreatable was a thing. It seems unfortunate
> > that we have accumulated three different kinds of object
> > creation/destruction life cycle:
> >
> > - instance_init / instance_finalize
>
> This is all stuff that is supposed to be basic self contanied
> initialization/cleanup with no side effects or dependencies,
> and impossible to fail, which is pretty clear semantics.
> During init, no external properties have been set yet, and
> during finalize it is already disconnected from the QOM tree.
> Essentially these should be basic memory allocs/free, mutex
> inits/destroys, setting default int values if non-zero, etc.
>
> > - instance_init / realize / unrealize / instance_finalize
> > - instance_init / complete / prepare_delete / instance_finalize
>
> These two have clear overlap in that they both take place after
> user specified properties have been set, and deal with types of
> initialization/setup/cleanup that can fail and have external
> depedencies.
>
> UserCreatable has another aspect in that it is the witness
> flag for whether a QOM type is permissible to create using
> -object / object_add.
>
> I've periodically wondered if we could make them the same, but
> the realize/unrealize phases have significantly more complexity
> and dependancies than the complete/prepare_delete and most
> notably, 'realize' has a 'bus' parameter.

No, it doesn't: the method signature is
typedef void (*DeviceRealize)(DeviceState *dev, Error **errp);
The qdev_realize() function takes a Bus pointer, but it doesn't
get passed to the device itself, only used to call
qdev_set_parent_bus(). (So arguably it would be better called
"qdev_realize_and_parent()" but that's a bit unwieldy.)

> I think that an approach to unification would end up with the
> 'Device' class implementing UserCreatable and providing a
> 'complete' method which in turn called the 'realize' method.
> IOW, nothing much would really change in terms of impls, as
> all Device subclasses would carry on using realize/unrealize.
> It would merely make Device tree available to -object/object_add.
> There are probably quite a few edge case problems hiding in
> there though if one were to actually try to do this, so the
> pragmatic option is really to ignore this all and accept the
> different APIs for Device vs non-Device QOM.

Probably. But I think the core reason we've ended up here
is that we didn't have the two-stage init in the core Object
type and so different subclasses have ended up implementing
very similar requirements differently. So if we did care
enough to tackle this I would favour pushing it up into Object.

-- PMM

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 23 Oct 2026 at 12:08, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> The memory backends are all implementing the UserCreatable
>> interface, which provides a "complete" method where they
>> could gracefully report lack of the feature via 'errp'.
>
> I didn't realize UserCreatable was a thing. It seems unfortunate
> that we have accumulated three different kinds of object
> creation/destruction life cycle:

Yes.  See also "Problem 5: QOM lacks a clear life cycle" in

    Subject: Dynamic & heterogeneous machines, initial configuration: problems
    Date: Wed, 31 Jan 2024 21:14:21 +0100
    Message-ID: <87o7d1i7ky.fsf@pond.sub.org>
    https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/    

> - instance_init / instance_finalize

All QOM types (but some add to this protocol).

> - instance_init / realize / unrealize / instance_finalize

Device types, i.e. subtypes of "device".

> - instance_init / complete / prepare_delete / instance_finalize

User-createble object types, i.e. types that provide interface
"user-creatable".  No device type does that.

Related: machine init done notifiers.

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Markus Armbruster]

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

> On Fri, Oct 23, 2026 at 11:44:10AM +0100, Peter Maydell wrote:
>> On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> >
>> > On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
>> > > My build of qemu-system-x86_64 has device sgx-epc:
>> > >
>> > >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
>> > >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
>> > >
>> > > The device as a link property to a memory-backend-epc:
>> > >
>> > >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
>> > >  <-- {"return": [...
>> > >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
>> > >                  ...]}
>> > >
>> > > However, type memory-backend-epc does not exist:
>> 
>> > There is some rather dubious code that conditionally registers
>> > the type
>> >
>> > 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);
>> >     }
>> > }
>> >
>> >
>> > Normal practice is for types to be unconditionally registered.  Do we
>> > have any examples outside of this SGX case where we conditionally
>> > register types ?   Should we change this to follow normal practice ?
>> 
>> TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
>> "calls to type_register not indented by exactly 4 spaces" and
>> I think the other cases are "misindented" or "data-driven
>> type registration" rather than trying to do things conditionally
>> (but I didn't actually look at all of them, instead making
>> guesses based on variable names, so maybe there's one or two
>> more I missed).
>> 
>> I guess maybe this is trying to work around the fact that the
>> memory backend API doesn't give a backend any place to say
>> "this is never going to work" early, because instance_init isn't
>> allowed to fail, these objects aren't TYPE_DEVICE so they
>> don't have "realize", and so the only other option is
>> "fail every alloc call" ?
>
> The memory backends are all implementing the UserCreatable
> interface, which provides a "complete" method where they
> could gracefully report lack of the feature via 'errp'.

Yes.

> This is not obvious since UserCreatable is implemented in
> the parent base class, but the subclasses could provide
> their own  'complete' impl and chain up the parent impl

David, Igor, can you clean this up?  Or would you like me to try?

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Igor Mammedov]

On Tue, 27 Oct 2026 07:40:24 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, Oct 23, 2026 at 11:44:10AM +0100, Peter Maydell wrote:  
> >> On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:  
> >> >
> >> > On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:  
> >> > > My build of qemu-system-x86_64 has device sgx-epc:
> >> > >  
> >> > >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}  
> >> > >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
> >> > >
> >> > > The device as a link property to a memory-backend-epc:
> >> > >  
> >> > >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}  
> >> > >  <-- {"return": [...
> >> > >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
> >> > >                  ...]}
> >> > >
> >> > > However, type memory-backend-epc does not exist:  
> >>   
> >> > There is some rather dubious code that conditionally registers
> >> > the type
> >> >
> >> > 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);
> >> >     }
> >> > }
> >> >
> >> >
> >> > Normal practice is for types to be unconditionally registered.  Do we
> >> > have any examples outside of this SGX case where we conditionally
> >> > register types ?   Should we change this to follow normal practice ?  
> >> 
> >> TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
> >> "calls to type_register not indented by exactly 4 spaces" and
> >> I think the other cases are "misindented" or "data-driven
> >> type registration" rather than trying to do things conditionally
> >> (but I didn't actually look at all of them, instead making
> >> guesses based on variable names, so maybe there's one or two
> >> more I missed).
> >> 
> >> I guess maybe this is trying to work around the fact that the
> >> memory backend API doesn't give a backend any place to say
> >> "this is never going to work" early, because instance_init isn't
> >> allowed to fail, these objects aren't TYPE_DEVICE so they
> >> don't have "realize", and so the only other option is
> >> "fail every alloc call" ?  
> >
> > The memory backends are all implementing the UserCreatable
> > interface, which provides a "complete" method where they
> > could gracefully report lack of the feature via 'errp'.  
> 
> Yes.
> 
> > This is not obvious since UserCreatable is implemented in
> > the parent base class, but the subclasses could provide
> > their own  'complete' impl and chain up the parent impl  
> 
> David, Igor, can you clean this up?  Or would you like me to try?

Please go ahead, I'm not likely to have bandwidth for upstream ATM. 

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Markus Armbruster]

Igor Mammedov <imammedo@redhat.com> writes:

> On Tue, 27 Oct 2026 07:40:24 +0100
> Markus Armbruster <armbru@redhat.com> wrote:
>> David, Igor, can you clean this up?  Or would you like me to try?
>
> Please go ahead, I'm not likely to have bandwidth for upstream ATM. 

Posted:

    Subject: [PATCH 0/7] backends/hostmem: Make QOM types and properties unconditional
    Date: Wed, 11 Nov 2026 13:23:35 +0100
    Message-ID: <20261111122342.634370-1-armbru@redhat.com>

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>
>> On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
>> > My build of qemu-system-x86_64 has device sgx-epc:
>> >
>> >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
>> >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
>> >
>> > The device as a link property to a memory-backend-epc:
>> >
>> >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
>> >  <-- {"return": [...
>> >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
>> >                  ...]}
>> >
>> > However, type memory-backend-epc does not exist:
>
>> There is some rather dubious code that conditionally registers
>> the type
>>
>> 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);
>>     }
>> }
>>
>>
>> Normal practice is for types to be unconditionally registered.  Do we
>> have any examples outside of this SGX case where we conditionally
>> register types ?   Should we change this to follow normal practice ?
>
> TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
> "calls to type_register not indented by exactly 4 spaces" and
> I think the other cases are "misindented" or "data-driven
> type registration" rather than trying to do things conditionally
> (but I didn't actually look at all of them, instead making
> guesses based on variable names, so maybe there's one or two
> more I missed).

Alright, I looked.  In addition to "misindented" or "data-driven", I
found:

* register_types() in hostmem-memfd.c registers "memory-backend-memfd"
  only when a test of memfd_create() succeeds.  This is what Peter
  reported.

* virtio_ccw_gpu_register() in hw/s390x/virtio-ccw-gpu.c registers
  "virtio-gpu-ccw" only when have_virtio_ccw, which is true when
  hw/s390x/virtio-ccw.c gets compiled into the binary.  So it's
  effectively compile-time conditional.

  I wish it was literally compile-time conditional, either in meson or
  using #if.

* qemu_console_early_init() in ui/console-vc.c registers "chardev-vc" if
  it's not already registered.  early_dbus_init() in ui/dbus.c,
  early_gtk_display_init() in ui/gtk.c, and
  spice_app_display_early_init() in ui/spice-app.c all register it.

  These are all QemuDisplay .early_init() callbacks.
  qemu_display_early_init() calls the selected display's .early_init(),
  if non-null.

  Because qemu_console_early_init() runs after
  qemu_display_early_init(), this always registers a "chardev-vc": the
  active display may register its own, and when it doesn't, we get
  ui/console-vc.c's.

  More moving parts than I'd like.

I'm going to post patches for backends/hostmem-{epc,memfd}.c.  I don't
plan to clean up the other two at this time.

[...]

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 01:16:36PM +0100, Markus Armbruster wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> > On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>
> >> On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
> >> > My build of qemu-system-x86_64 has device sgx-epc:
> >> >
> >> >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
> >> >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
> >> >
> >> > The device as a link property to a memory-backend-epc:
> >> >
> >> >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
> >> >  <-- {"return": [...
> >> >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
> >> >                  ...]}
> >> >
> >> > However, type memory-backend-epc does not exist:
> >
> >> There is some rather dubious code that conditionally registers
> >> the type
> >>
> >> 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);
> >>     }
> >> }
> >>
> >>
> >> Normal practice is for types to be unconditionally registered.  Do we
> >> have any examples outside of this SGX case where we conditionally
> >> register types ?   Should we change this to follow normal practice ?
> >
> > TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
> > "calls to type_register not indented by exactly 4 spaces" and
> > I think the other cases are "misindented" or "data-driven
> > type registration" rather than trying to do things conditionally
> > (but I didn't actually look at all of them, instead making
> > guesses based on variable names, so maybe there's one or two
> > more I missed).
> 
> Alright, I looked.  In addition to "misindented" or "data-driven", I
> found:
> 
> * register_types() in hostmem-memfd.c registers "memory-backend-memfd"
>   only when a test of memfd_create() succeeds.  This is what Peter
>   reported.
> 
> * virtio_ccw_gpu_register() in hw/s390x/virtio-ccw-gpu.c registers
>   "virtio-gpu-ccw" only when have_virtio_ccw, which is true when
>   hw/s390x/virtio-ccw.c gets compiled into the binary.  So it's
>   effectively compile-time conditional.
> 
>   I wish it was literally compile-time conditional, either in meson or
>   using #if.

That looks like it is dead code to me. hw/s390x/meson.build does

  hw_s390x_modules = {}
  virtio_gpu_ccw_ss = ss.source_set()
  virtio_gpu_ccw_ss.add(when: ['CONFIG_VIRTIO_GPU', 'CONFIG_VIRTIO_CCW'],
                        if_true: [files('virtio-ccw-gpu.c'), pixman])
  hw_s390x_modules += {'virtio-gpu-ccw': virtio_gpu_ccw_ss}

it doesn't look like 'have_virtio_ccw' can ever be false, due
to the CONFIG_VIRTIO_CCW Kconfig check ?

> 
> * qemu_console_early_init() in ui/console-vc.c registers "chardev-vc" if
>   it's not already registered.  early_dbus_init() in ui/dbus.c,
>   early_gtk_display_init() in ui/gtk.c, and
>   spice_app_display_early_init() in ui/spice-app.c all register it.
> 
>   These are all QemuDisplay .early_init() callbacks.
>   qemu_display_early_init() calls the selected display's .early_init(),
>   if non-null.
> 
>   Because qemu_console_early_init() runs after
>   qemu_display_early_init(), this always registers a "chardev-vc": the
>   active display may register its own, and when it doesn't, we get
>   ui/console-vc.c's.
> 
>   More moving parts than I'd like.
> 
> I'm going to post patches for backends/hostmem-{epc,memfd}.c.  I don't
> plan to clean up the other two at this time.
> 
> [...]
> 

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: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Cornelia Huck]

On Wed, Nov 11 2026, Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Wed, Nov 11, 2026 at 01:16:36PM +0100, Markus Armbruster wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> 
>> > On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> >>
>> >> On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
>> >> > My build of qemu-system-x86_64 has device sgx-epc:
>> >> >
>> >> >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
>> >> >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
>> >> >
>> >> > The device as a link property to a memory-backend-epc:
>> >> >
>> >> >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
>> >> >  <-- {"return": [...
>> >> >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
>> >> >                  ...]}
>> >> >
>> >> > However, type memory-backend-epc does not exist:
>> >
>> >> There is some rather dubious code that conditionally registers
>> >> the type
>> >>
>> >> 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);
>> >>     }
>> >> }
>> >>
>> >>
>> >> Normal practice is for types to be unconditionally registered.  Do we
>> >> have any examples outside of this SGX case where we conditionally
>> >> register types ?   Should we change this to follow normal practice ?
>> >
>> > TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
>> > "calls to type_register not indented by exactly 4 spaces" and
>> > I think the other cases are "misindented" or "data-driven
>> > type registration" rather than trying to do things conditionally
>> > (but I didn't actually look at all of them, instead making
>> > guesses based on variable names, so maybe there's one or two
>> > more I missed).
>> 
>> Alright, I looked.  In addition to "misindented" or "data-driven", I
>> found:
>> 
>> * register_types() in hostmem-memfd.c registers "memory-backend-memfd"
>>   only when a test of memfd_create() succeeds.  This is what Peter
>>   reported.
>> 
>> * virtio_ccw_gpu_register() in hw/s390x/virtio-ccw-gpu.c registers
>>   "virtio-gpu-ccw" only when have_virtio_ccw, which is true when
>>   hw/s390x/virtio-ccw.c gets compiled into the binary.  So it's
>>   effectively compile-time conditional.
>> 
>>   I wish it was literally compile-time conditional, either in meson or
>>   using #if.
>
> That looks like it is dead code to me. hw/s390x/meson.build does
>
>   hw_s390x_modules = {}
>   virtio_gpu_ccw_ss = ss.source_set()
>   virtio_gpu_ccw_ss.add(when: ['CONFIG_VIRTIO_GPU', 'CONFIG_VIRTIO_CCW'],
>                         if_true: [files('virtio-ccw-gpu.c'), pixman])
>   hw_s390x_modules += {'virtio-gpu-ccw': virtio_gpu_ccw_ss}
>
> it doesn't look like 'have_virtio_ccw' can ever be false, due
> to the CONFIG_VIRTIO_CCW Kconfig check ?

adcf33a504de ("s390x: modularize virtio-gpu-ccw") seems to indicate that
this is needed for virtio-gpu-ccw being a module, not sure if that is
still the case.

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Daniel P. Berrangé]

On Wed, Nov 11, 2026 at 02:33:03PM +0100, Cornelia Huck wrote:
> On Wed, Nov 11 2026, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> > On Wed, Nov 11, 2026 at 01:16:36PM +0100, Markus Armbruster wrote:
> >> Peter Maydell <peter.maydell@linaro.org> writes:
> >> 
> >> > On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >> >>
> >> >> On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
> >> >> > My build of qemu-system-x86_64 has device sgx-epc:
> >> >> >
> >> >> >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
> >> >> >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
> >> >> >
> >> >> > The device as a link property to a memory-backend-epc:
> >> >> >
> >> >> >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
> >> >> >  <-- {"return": [...
> >> >> >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
> >> >> >                  ...]}
> >> >> >
> >> >> > However, type memory-backend-epc does not exist:
> >> >
> >> >> There is some rather dubious code that conditionally registers
> >> >> the type
> >> >>
> >> >> 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);
> >> >>     }
> >> >> }
> >> >>
> >> >>
> >> >> Normal practice is for types to be unconditionally registered.  Do we
> >> >> have any examples outside of this SGX case where we conditionally
> >> >> register types ?   Should we change this to follow normal practice ?
> >> >
> >> > TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
> >> > "calls to type_register not indented by exactly 4 spaces" and
> >> > I think the other cases are "misindented" or "data-driven
> >> > type registration" rather than trying to do things conditionally
> >> > (but I didn't actually look at all of them, instead making
> >> > guesses based on variable names, so maybe there's one or two
> >> > more I missed).
> >> 
> >> Alright, I looked.  In addition to "misindented" or "data-driven", I
> >> found:
> >> 
> >> * register_types() in hostmem-memfd.c registers "memory-backend-memfd"
> >>   only when a test of memfd_create() succeeds.  This is what Peter
> >>   reported.
> >> 
> >> * virtio_ccw_gpu_register() in hw/s390x/virtio-ccw-gpu.c registers
> >>   "virtio-gpu-ccw" only when have_virtio_ccw, which is true when
> >>   hw/s390x/virtio-ccw.c gets compiled into the binary.  So it's
> >>   effectively compile-time conditional.
> >> 
> >>   I wish it was literally compile-time conditional, either in meson or
> >>   using #if.
> >
> > That looks like it is dead code to me. hw/s390x/meson.build does
> >
> >   hw_s390x_modules = {}
> >   virtio_gpu_ccw_ss = ss.source_set()
> >   virtio_gpu_ccw_ss.add(when: ['CONFIG_VIRTIO_GPU', 'CONFIG_VIRTIO_CCW'],
> >                         if_true: [files('virtio-ccw-gpu.c'), pixman])
> >   hw_s390x_modules += {'virtio-gpu-ccw': virtio_gpu_ccw_ss}
> >
> > it doesn't look like 'have_virtio_ccw' can ever be false, due
> > to the CONFIG_VIRTIO_CCW Kconfig check ?
> 
> adcf33a504de ("s390x: modularize virtio-gpu-ccw") seems to indicate that
> this is needed for virtio-gpu-ccw being a module, not sure if that is
> still the case.

I'm not understanding why modules affects this though ?

If CONFIG_VIRTIO_CCW is set, then we know virtio-ccw is builtin,
and the module loading for virtio-gpu-ccw is fine.

If CONFIG_VIRTIO_CCW is unset, then neither virtio-gpu-ccw or
virtio-ccw are built at all, so there's no module to load.

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: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Cornelia Huck]

On Wed, Nov 11 2026, Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Wed, Nov 11, 2026 at 02:33:03PM +0100, Cornelia Huck wrote:
>> On Wed, Nov 11 2026, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> 
>> > On Wed, Nov 11, 2026 at 01:16:36PM +0100, Markus Armbruster wrote:
>> >> Peter Maydell <peter.maydell@linaro.org> writes:
>> >> 
>> >> > On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> >> >>
>> >> >> On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
>> >> >> > My build of qemu-system-x86_64 has device sgx-epc:
>> >> >> >
>> >> >> >  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
>> >> >> >  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
>> >> >> >
>> >> >> > The device as a link property to a memory-backend-epc:
>> >> >> >
>> >> >> >  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
>> >> >> >  <-- {"return": [...
>> >> >> >                  {"name": "memdev", "type": "link<memory-backend-epc>"},
>> >> >> >                  ...]}
>> >> >> >
>> >> >> > However, type memory-backend-epc does not exist:
>> >> >
>> >> >> There is some rather dubious code that conditionally registers
>> >> >> the type
>> >> >>
>> >> >> 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);
>> >> >>     }
>> >> >> }
>> >> >>
>> >> >>
>> >> >> Normal practice is for types to be unconditionally registered.  Do we
>> >> >> have any examples outside of this SGX case where we conditionally
>> >> >> register types ?   Should we change this to follow normal practice ?
>> >> >
>> >> > TYPE_MEMORY_BACKEND_MEMFD does the same. I did a quick grep for
>> >> > "calls to type_register not indented by exactly 4 spaces" and
>> >> > I think the other cases are "misindented" or "data-driven
>> >> > type registration" rather than trying to do things conditionally
>> >> > (but I didn't actually look at all of them, instead making
>> >> > guesses based on variable names, so maybe there's one or two
>> >> > more I missed).
>> >> 
>> >> Alright, I looked.  In addition to "misindented" or "data-driven", I
>> >> found:
>> >> 
>> >> * register_types() in hostmem-memfd.c registers "memory-backend-memfd"
>> >>   only when a test of memfd_create() succeeds.  This is what Peter
>> >>   reported.
>> >> 
>> >> * virtio_ccw_gpu_register() in hw/s390x/virtio-ccw-gpu.c registers
>> >>   "virtio-gpu-ccw" only when have_virtio_ccw, which is true when
>> >>   hw/s390x/virtio-ccw.c gets compiled into the binary.  So it's
>> >>   effectively compile-time conditional.
>> >> 
>> >>   I wish it was literally compile-time conditional, either in meson or
>> >>   using #if.
>> >
>> > That looks like it is dead code to me. hw/s390x/meson.build does
>> >
>> >   hw_s390x_modules = {}
>> >   virtio_gpu_ccw_ss = ss.source_set()
>> >   virtio_gpu_ccw_ss.add(when: ['CONFIG_VIRTIO_GPU', 'CONFIG_VIRTIO_CCW'],
>> >                         if_true: [files('virtio-ccw-gpu.c'), pixman])
>> >   hw_s390x_modules += {'virtio-gpu-ccw': virtio_gpu_ccw_ss}
>> >
>> > it doesn't look like 'have_virtio_ccw' can ever be false, due
>> > to the CONFIG_VIRTIO_CCW Kconfig check ?
>> 
>> adcf33a504de ("s390x: modularize virtio-gpu-ccw") seems to indicate that
>> this is needed for virtio-gpu-ccw being a module, not sure if that is
>> still the case.
>
> I'm not understanding why modules affects this though ?

Yeah, me neither.

>
> If CONFIG_VIRTIO_CCW is set, then we know virtio-ccw is builtin,
> and the module loading for virtio-gpu-ccw is fine.
>
> If CONFIG_VIRTIO_CCW is unset, then neither virtio-gpu-ccw or
> virtio-ccw are built at all, so there's no module to load.

Gerd, Halil: do you remember why this is needed?

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Markus Armbruster]

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

> On Thu, Oct 22, 2026 at 02:58:16PM +0200, Markus Armbruster wrote:
>> My build of qemu-system-x86_64 has device sgx-epc:
>> 
>>  --> {"execute": "qom-list-types", "arguments": {"implements": "sgx-epc"}}
>>  <-- {"return": [{"name": "sgx-epc", "parent": "device"}]}
>> 
>> The device as a link property to a memory-backend-epc:
>> 
>>  --> {"execute": "qom-list-properties", "arguments": {"typename": "sgx-epc"}}
>>  <-- {"return": [...
>>                  {"name": "memdev", "type": "link<memory-backend-epc>"},
>>                  ...]}
>> 
>> However, type memory-backend-epc does not exist:
>> 
>>  --> {"execute": "qom-list-types", "arguments": {"implements": "memory-backend"}}
>>  <-- {"return": [{"name": "memory-backend-ram", "parent": "memory-backend"}, {"name": "memory-backend-file", "parent": "memory-backend"}, {"name": "memory-backend-memfd", "parent": "memory-backend"}, {"name": "memory-backend-shm", "parent": "memory-backend"}]}
>
> There is some rather dubious code that conditionally registers
> the type
>
> 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);
>     }
> }
>
>
> Normal practice is for types to be unconditionally registered.  Do we
> have any examples outside of this SGX case where we conditionally
> register types ?   Should we change this to follow normal practice ?

Loosely related: conditional *class* properties.  Example:

    static void
    memfd_backend_class_init(ObjectClass *oc, const void *data)
    {
        HostMemoryBackendClass *bc = MEMORY_BACKEND_CLASS(oc);

        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)");
        }

        [...]
    }

These properties are also declared in qapi/qom.json if CONFIG_LINUX.
QAPI introspection (query-qmp-schema) shows them then.  QOM
introspection (qom-list-properties etc.) only shows them when the
MFD_HUGETLB check succeeded.

Feels undesirable to me.

Should we instead make them read-only when the check fails?

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Markus Armbruster]

Markus Armbruster <armbru@redhat.com> writes:

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

[...]

>> Normal practice is for types to be unconditionally registered.  Do we
>> have any examples outside of this SGX case where we conditionally
>> register types ?   Should we change this to follow normal practice ?
>
> Loosely related: conditional *class* properties.  Example:
>
>     static void
>     memfd_backend_class_init(ObjectClass *oc, const void *data)
>     {
>         HostMemoryBackendClass *bc = MEMORY_BACKEND_CLASS(oc);
>
>         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)");
>         }
>
>         [...]
>     }
>
> These properties are also declared in qapi/qom.json if CONFIG_LINUX.
> QAPI introspection (query-qmp-schema) shows them then.  QOM
> introspection (qom-list-properties etc.) only shows them when the
> MFD_HUGETLB check succeeded.
>
> Feels undesirable to me.

[...]

Conditional turned out to be unnecessary here:

    Subject: [PATCH 7/7] backends/hostmem-memfd: Add huge TLB properties unconditionally
    Date: Wed, 11 Nov 2026 13:23:42 +0100
    Message-ID: <20261111122342.634370-8-armbru@redhat.com>

I found a few more:

* Property "loadparm" of scsi-cd, scsi-hd, virtio-blk-pci,
  virtio-net-pci only if target_s390x()

* Several properties of xenpvh-machine on ARM and i386 only if
  ->has_virtio_mmio, ->has_pci, ->has_tpm

I don't plan to examine these.

Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

[Daniel P. Berrangé]

On Thu, Nov 12, 2026 at 01:15:25PM +0100, Markus Armbruster wrote:
> Markus Armbruster <armbru@redhat.com> writes:
> 
> > Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> [...]
> 
> >> Normal practice is for types to be unconditionally registered.  Do we
> >> have any examples outside of this SGX case where we conditionally
> >> register types ?   Should we change this to follow normal practice ?
> >
> > Loosely related: conditional *class* properties.  Example:
> >
> >     static void
> >     memfd_backend_class_init(ObjectClass *oc, const void *data)
> >     {
> >         HostMemoryBackendClass *bc = MEMORY_BACKEND_CLASS(oc);
> >
> >         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)");
> >         }
> >
> >         [...]
> >     }
> >
> > These properties are also declared in qapi/qom.json if CONFIG_LINUX.
> > QAPI introspection (query-qmp-schema) shows them then.  QOM
> > introspection (qom-list-properties etc.) only shows them when the
> > MFD_HUGETLB check succeeded.
> >
> > Feels undesirable to me.
> 
> [...]
> 
> Conditional turned out to be unnecessary here:
> 
>     Subject: [PATCH 7/7] backends/hostmem-memfd: Add huge TLB properties unconditionally
>     Date: Wed, 11 Nov 2026 13:23:42 +0100
>     Message-ID: <20261111122342.634370-8-armbru@redhat.com>
> 
> I found a few more:
> 
> * Property "loadparm" of scsi-cd, scsi-hd, virtio-blk-pci,
>   virtio-net-pci only if target_s390x()
> 
> * Several properties of xenpvh-machine on ARM and i386 only if
>   ->has_virtio_mmio, ->has_pci, ->has_tpm
> 
> I don't plan to examine these.

The 'loadparm' issue is one that we need to fix for the multi-target
work. We need a unified QOM tree that is invariant across targets,
so that property should become unconditional. Checks for invalid
usage must be done at realize() time instead.

Yonggang had some patches for this which I've included  in a proposed
series I just CC'd you on:

  https://lists.gnu.org/archive/html/qemu-devel/2026-11/msg02739.html
  https://lists.gnu.org/archive/html/qemu-devel/2026-11/msg02740.html

and 'virtio-mem' was another example

  https://lists.gnu.org/archive/html/qemu-devel/2026-11/msg02750.html

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 :|