Daniel P. Berrangé <[email protected]> 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é <[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" ? > > 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?
