On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrangé <[email protected]> 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
