[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3] xen: Remove dependency between pciback and privcmd
On 2024/10/12 10:22, Chen, Jiqian wrote: > On 2024/10/11 20:06, Juergen Gross wrote: >> On 11.10.24 05:42, Jiqian Chen wrote: >>> Commit 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") >>> adds a weak reverse dependency to the config XEN_PRIVCMD definition, that >>> dependency causes xen-privcmd can't be loaded on domU, because dependent >>> xen-pciback isn't always be loaded successfully on domU. >>> >>> To solve above problem, remove that dependency, and do not call >>> pcistub_get_gsi_from_sbdf() directly, instead add a hook in >>> drivers/xen/apci.c, xen-pciback register the real call function, then in >>> privcmd_ioctl_pcidev_get_gsi call that hook. >>> >>> Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") >>> Reported-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> >>> Signed-off-by: Jiqian Chen <Jiqian.Chen@xxxxxxx> >> >> Unfortunately I'm seeing a build breakage for the 32-bit x86 build. Could you please attach the link or steps? Then I can reproduce it, and validate it locally with new changes. >> >> Reason is that drivers/xen/acpi.c is being built for Dom0 only, so having >> CONFIG_XEN_ACPI defined is not enough for ensuring the new functions are >> present. >> >> I suggest to add a new CONFIG item CONFIG_XEN_DOM0_ACPI like >> >> config XEN_DOM0_ACPI >> def_bool y >> depends on XEN_ACPI && XEN_DOM0 >> >> and then replace all CONFIG_XEN_ACPI instances in your patch with >> CONFIG_XEN_DOM0_ACPI. This includes the use case in >> privcmd_ioctl_pcidev_get_gsi(). > > How about add stubs for xen_acpi_register_get_gsi_func and > xen_acpi_get_gsi_from_sbdf when "!CONFIG_XEN_DOM0" in acpi.h, like the other > functions in that file do. > >> >> >> Juergen > -- Best regards, Jiqian Chen.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |