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?