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