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

[Markus Armbruster <armbru@redhat.com>]

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?