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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Nov 11, 2026 at 02:33:03PM +0100, Cornelia Huck wrote:
> On Wed, Nov 11 2026, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> > On Wed, Nov 11, 2026 at 01:16:36PM +0100, Markus Armbruster wrote:
> >> Peter Maydell <peter.maydell@linaro.org> writes:
> >> 
> >> > 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).
> >> 
> >> Alright, I looked.  In addition to "misindented" or "data-driven", I
> >> found:
> >> 
> >> * register_types() in hostmem-memfd.c registers "memory-backend-memfd"
> >>   only when a test of memfd_create() succeeds.  This is what Peter
> >>   reported.
> >> 
> >> * virtio_ccw_gpu_register() in hw/s390x/virtio-ccw-gpu.c registers
> >>   "virtio-gpu-ccw" only when have_virtio_ccw, which is true when
> >>   hw/s390x/virtio-ccw.c gets compiled into the binary.  So it's
> >>   effectively compile-time conditional.
> >> 
> >>   I wish it was literally compile-time conditional, either in meson or
> >>   using #if.
> >
> > That looks like it is dead code to me. hw/s390x/meson.build does
> >
> >   hw_s390x_modules = {}
> >   virtio_gpu_ccw_ss = ss.source_set()
> >   virtio_gpu_ccw_ss.add(when: ['CONFIG_VIRTIO_GPU', 'CONFIG_VIRTIO_CCW'],
> >                         if_true: [files('virtio-ccw-gpu.c'), pixman])
> >   hw_s390x_modules += {'virtio-gpu-ccw': virtio_gpu_ccw_ss}
> >
> > it doesn't look like 'have_virtio_ccw' can ever be false, due
> > to the CONFIG_VIRTIO_CCW Kconfig check ?
> 
> adcf33a504de ("s390x: modularize virtio-gpu-ccw") seems to indicate that
> this is needed for virtio-gpu-ccw being a module, not sure if that is
> still the case.

I'm not understanding why modules affects this though ?

If CONFIG_VIRTIO_CCW is set, then we know virtio-ccw is builtin,
and the module loading for virtio-gpu-ccw is fine.

If CONFIG_VIRTIO_CCW is unset, then neither virtio-gpu-ccw or
virtio-ccw are built at all, so there's no module to load.

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