On Tue, Mar 05, 2024 at 08:12:29PM +0100, Marek Marczykowski-Górecki wrote:
> diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
> index 124dd5f3d6..6bd4e6eb2f 100644
> --- a/hw/xen/xen-legacy-backend.c
> +++ b/hw/xen/xen-legacy-backend.c
> @@ -603,6 +603,20 @@ static void xen_set_dynamic_sysbus(void)
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_XENSYSDEV);
> }
>
> +static bool xen_check_stubdomain(void)
> +{
> + char *dm_path = g_strdup_printf("/local/domain/%d/image", xen_domid);
> + int32_t dm_domid;
> + bool is_stubdom = false;
> +
> + if (!xenstore_read_int(dm_path, "device-model-domid", &dm_domid)) {
> + is_stubdom = dm_domid != 0;
> + }
> +
> + g_free(dm_path);
> + return is_stubdom;
> +}
> +
> void xen_be_init(void)
> {
> xenstore = qemu_xen_xs_open();
> @@ -616,6 +630,8 @@ void xen_be_init(void)
> exit(1);
> }
>
> + xen_is_stubdomain = xen_check_stubdomain();
This isn't really a backend specific information, and xen_be_init() is
all about old backend implementation support. (qdisk which have been the
first to be rewritten doesn't need xen_be_init(), or shouldn't). Could
we move the initialisation elsewhere?
Is this relevant PV guests? If not, we could move the initialisation to
xen_hvm_init_pc().
Also, avoid having xen_check_stubdomain() depending on
"xen-legacy-backend", if possible.
(In xen_hvm_init_pc(), a call to xen_register_ioreq() opens another
xenstore, as `state->xenstore`.)
(There's already been effort to build QEMU without legacy backends, that
stubdom check would break in this scenario.)
Thanks,
--
Anthony PERARD
