On Tue, 27 Oct 2026 07:40:24 +0100 Markus Armbruster <[email protected]> wrote:
> 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? Please go ahead, I'm not likely to have bandwidth for upstream ATM.
