From: Cornelia Huck <cohuck@redhat.com>
To: =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, Markus
 Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org, David
 Hildenbrand <david@kernel.org>, Igor Mammedov <imammedo@redhat.com>, Paolo
 Bonzini <pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>,
 "Michael S. Tsirkin" <mst@redhat.com>, Richard Henderson
 <richard.henderson@linaro.org>, Halil Pasic <pasic@linux.ibm.com>, Eric
 Farman <farman@linux.ibm.com>, qemu-s390x@nongnu.org, =?utf-8?Q?Marc-Andr?=
 =?utf-8?Q?=C3=A9?= Lureau <marcandre.lureau@redhat.com>
Subject: Re: qemu-system-x86_64 appears to have sgx-epc, but not
 memory-backend-epc
In-Reply-To: <avRfKD2snrmJC3c-@redhat.com>
Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630
 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB
 153243,
 =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera,
 Avril Crosse O'Flaherty"
References: <87zew5j3iv.fsf@pond.sub.org> <ats0_RfeVugAofN9@redhat.com>
 <CAFEAcA_wabjzp0KF69-ay75QoOk=jE-TygrD-T-b60dw1iOs=g@mail.gmail.com>
 <87bj7vwokb.fsf@pond.sub.org> <avRfKD2snrmJC3c-@redhat.com>
User-Agent: Notmuch/0.40 (https://notmuchmail.org)
Date: Wed, 11 Nov 2026 14:33:03 +0100
Message-ID: <87jymjwl0w.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=170.10.133.124; envelope-from=cohuck@redhat.com;
 helo=us-smtp-delivery-124.mimecast.com
X-Spam_score_int: 5
X-Spam_score: 0.5
X-Spam_bar: /
X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,
 DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-BeenThere: qemu-devel@nongnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: qemu development <qemu-devel.nongnu.org>
List-Archive: <https://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
 <mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org
X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=no
	autolearn_force=no version=4.0.1
X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on
	aws-us-west-2-korg-listserv-alma10-1

On Wed, Nov 11 2026, Daniel P. Berrang=C3=A9 <berrange@redhat.com> wrote:

> On Wed, Nov 11, 2026 at 01:16:36PM +0100, Markus Armbruster wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>=20
>> > On Fri, 23 Oct 2026 at 11:21, Daniel P. Berrang=C3=A9 <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-ep=
c>"},
>> >> >                  ...]}
>> >> >
>> >> > 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 =3D qemu_open_old("/dev/sgx_vepc", O_RDWR);
>> >>     if (fd >=3D 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).
>>=20
>> Alright, I looked.  In addition to "misindented" or "data-driven", I
>> found:
>>=20
>> * register_types() in hostmem-memfd.c registers "memory-backend-memfd"
>>   only when a test of memfd_create() succeeds.  This is what Peter
>>   reported.
>>=20
>> * 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.
>>=20
>>   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 =3D {}
>   virtio_gpu_ccw_ss =3D 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 +=3D {'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.