| Message ID | 20241009062014.407310-1-Jiqian.Chen@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | xen: Remove config dependency in XEN_PRIVCMD definition | expand |
On 09.10.2024 08:20, 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, its > purpose is to pass the combination of compilation that CONFIG_XEN_PRIVCMD=y > and CONFIG_XEN_PCIDEV_BACKEND=m, because in that combination, xen-pciback > is compiled as a module but xen-privcmd is built-in, so xen-privcmd can't > find the implementation of pcistub_get_gsi_from_sbdf. > > But that dependency causes xen-privcmd can't be loaded on domU, because > dependent xen-pciback is always not be loaded successfully on domU. > > To solve above problem and cover original commit's requirement, just remove > that dependency, because the code "IS_REACHABLE(CONFIG_XEN_PCIDEV_BACKEND)" > of original commit is enough to meet the requirement. > > Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> This lacks a Reported-by:. > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -261,7 +261,6 @@ config XEN_SCSI_BACKEND > config XEN_PRIVCMD > tristate "Xen hypercall passthrough driver" > depends on XEN > - imply XEN_PCIDEV_BACKEND > default m > help > The hypercall passthrough driver allows privileged user programs to The report wasn't about a build problem, but a runtime one. Removing the dependency here doesn't change anything in the dependency of xen-privcmd on xen-pciback, as the use of pcistub_get_gsi_from_sbdf() continues to exist. Consider the case of XEN_PCIDEV_BACKEND=m and XEN_PRIVCMD=m, which I guess is what Marek is using in his config. Both drivers are available in such a configuration, yet loading of xen-privcmd then requires to load xen-pciback first. And that latter load attempt will fail in a DomU. The two drivers simply may not have any dependency in either direction. Jan
On Wed, 9 Oct 2024, Jan Beulich wrote: > On 09.10.2024 08:20, 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, its > > purpose is to pass the combination of compilation that CONFIG_XEN_PRIVCMD=y > > and CONFIG_XEN_PCIDEV_BACKEND=m, because in that combination, xen-pciback > > is compiled as a module but xen-privcmd is built-in, so xen-privcmd can't > > find the implementation of pcistub_get_gsi_from_sbdf. > > > > But that dependency causes xen-privcmd can't be loaded on domU, because > > dependent xen-pciback is always not be loaded successfully on domU. > > > > To solve above problem and cover original commit's requirement, just remove > > that dependency, because the code "IS_REACHABLE(CONFIG_XEN_PCIDEV_BACKEND)" > > of original commit is enough to meet the requirement. > > > > Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") > > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> > > This lacks a Reported-by:. > > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -261,7 +261,6 @@ config XEN_SCSI_BACKEND > > config XEN_PRIVCMD > > tristate "Xen hypercall passthrough driver" > > depends on XEN > > - imply XEN_PCIDEV_BACKEND > > default m > > help > > The hypercall passthrough driver allows privileged user programs to > > The report wasn't about a build problem, but a runtime one. Removing the > dependency here doesn't change anything in the dependency of xen-privcmd > on xen-pciback, as the use of pcistub_get_gsi_from_sbdf() continues to > exist. > > Consider the case of XEN_PCIDEV_BACKEND=m and XEN_PRIVCMD=m, which > I guess is what Marek is using in his config. Both drivers are available > in such a configuration, yet loading of xen-privcmd then requires to > load xen-pciback first. And that latter load attempt will fail in a DomU. > The two drivers simply may not have any dependency in either direction. The idea is that there should be no hard dependency on pcistub_get_gsi_from_sbdf(). If it is available, the service will be used, otherwise an error will be reported. The problem is that IS_REACHABLE is a compile-time check. What we need is a runtime check instead. Maybe symbol_get or try_module_get ?
On 10.10.24 00:46, Stefano Stabellini wrote: > On Wed, 9 Oct 2024, Jan Beulich wrote: >> On 09.10.2024 08:20, 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, its >>> purpose is to pass the combination of compilation that CONFIG_XEN_PRIVCMD=y >>> and CONFIG_XEN_PCIDEV_BACKEND=m, because in that combination, xen-pciback >>> is compiled as a module but xen-privcmd is built-in, so xen-privcmd can't >>> find the implementation of pcistub_get_gsi_from_sbdf. >>> >>> But that dependency causes xen-privcmd can't be loaded on domU, because >>> dependent xen-pciback is always not be loaded successfully on domU. >>> >>> To solve above problem and cover original commit's requirement, just remove >>> that dependency, because the code "IS_REACHABLE(CONFIG_XEN_PCIDEV_BACKEND)" >>> of original commit is enough to meet the requirement. >>> >>> Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") >>> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >> >> This lacks a Reported-by:. >> >>> --- a/drivers/xen/Kconfig >>> +++ b/drivers/xen/Kconfig >>> @@ -261,7 +261,6 @@ config XEN_SCSI_BACKEND >>> config XEN_PRIVCMD >>> tristate "Xen hypercall passthrough driver" >>> depends on XEN >>> - imply XEN_PCIDEV_BACKEND >>> default m >>> help >>> The hypercall passthrough driver allows privileged user programs to >> >> The report wasn't about a build problem, but a runtime one. Removing the >> dependency here doesn't change anything in the dependency of xen-privcmd >> on xen-pciback, as the use of pcistub_get_gsi_from_sbdf() continues to >> exist. >> >> Consider the case of XEN_PCIDEV_BACKEND=m and XEN_PRIVCMD=m, which >> I guess is what Marek is using in his config. Both drivers are available >> in such a configuration, yet loading of xen-privcmd then requires to >> load xen-pciback first. And that latter load attempt will fail in a DomU. >> The two drivers simply may not have any dependency in either direction. > > The idea is that there should be no hard dependency on > pcistub_get_gsi_from_sbdf(). If it is available, the service will be > used, otherwise an error will be reported. > > The problem is that IS_REACHABLE is a compile-time check. What we need > is a runtime check instead. Maybe symbol_get or try_module_get ? This is a rather clumsy solution IMO. I'm seeing the following solutions: 1. Don't fail to to load the pciback driver in a DomU, but only disable any functionality. 2. Move the drivers/xen/xen-pciback/pci_stub.c functionality in a module of its own, allowing the privcmd driver to be loaded without needing the rest of pciback. 3. Add a hook to e.g. drivers/xen/pci.c instead for calling of pcistub_get_gsi_from_sbdf() directly. pciback could register the real call address. If pciback isn't loaded, the hook can return an error. This would remove the explicit dependency of privcmd on pciback. I'd prefer the 3rd variant. Juergen
On 10.10.2024 07:39, Jürgen Groß wrote: > On 10.10.24 00:46, Stefano Stabellini wrote: >> On Wed, 9 Oct 2024, Jan Beulich wrote: >>> On 09.10.2024 08:20, 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, its >>>> purpose is to pass the combination of compilation that CONFIG_XEN_PRIVCMD=y >>>> and CONFIG_XEN_PCIDEV_BACKEND=m, because in that combination, xen-pciback >>>> is compiled as a module but xen-privcmd is built-in, so xen-privcmd can't >>>> find the implementation of pcistub_get_gsi_from_sbdf. >>>> >>>> But that dependency causes xen-privcmd can't be loaded on domU, because >>>> dependent xen-pciback is always not be loaded successfully on domU. >>>> >>>> To solve above problem and cover original commit's requirement, just remove >>>> that dependency, because the code "IS_REACHABLE(CONFIG_XEN_PCIDEV_BACKEND)" >>>> of original commit is enough to meet the requirement. >>>> >>>> Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") >>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >>> >>> This lacks a Reported-by:. >>> >>>> --- a/drivers/xen/Kconfig >>>> +++ b/drivers/xen/Kconfig >>>> @@ -261,7 +261,6 @@ config XEN_SCSI_BACKEND >>>> config XEN_PRIVCMD >>>> tristate "Xen hypercall passthrough driver" >>>> depends on XEN >>>> - imply XEN_PCIDEV_BACKEND >>>> default m >>>> help >>>> The hypercall passthrough driver allows privileged user programs to >>> >>> The report wasn't about a build problem, but a runtime one. Removing the >>> dependency here doesn't change anything in the dependency of xen-privcmd >>> on xen-pciback, as the use of pcistub_get_gsi_from_sbdf() continues to >>> exist. >>> >>> Consider the case of XEN_PCIDEV_BACKEND=m and XEN_PRIVCMD=m, which >>> I guess is what Marek is using in his config. Both drivers are available >>> in such a configuration, yet loading of xen-privcmd then requires to >>> load xen-pciback first. And that latter load attempt will fail in a DomU. >>> The two drivers simply may not have any dependency in either direction. >> >> The idea is that there should be no hard dependency on >> pcistub_get_gsi_from_sbdf(). If it is available, the service will be >> used, otherwise an error will be reported. >> >> The problem is that IS_REACHABLE is a compile-time check. What we need >> is a runtime check instead. Maybe symbol_get or try_module_get ? > > This is a rather clumsy solution IMO. > > I'm seeing the following solutions: > > 1. Don't fail to to load the pciback driver in a DomU, but only disable > any functionality. > > 2. Move the drivers/xen/xen-pciback/pci_stub.c functionality in a module > of its own, allowing the privcmd driver to be loaded without needing > the rest of pciback. > > 3. Add a hook to e.g. drivers/xen/pci.c instead for calling of > pcistub_get_gsi_from_sbdf() directly. pciback could register the real > call address. If pciback isn't loaded, the hook can return an error. > This would remove the explicit dependency of privcmd on pciback. > > I'd prefer the 3rd variant. Same here - order of preference backwards in the set presented above. In the meantime the original change may simply need reverting? Jan
On 2024/10/10 13:39, Jürgen Groß wrote: > On 10.10.24 00:46, Stefano Stabellini wrote: >> On Wed, 9 Oct 2024, Jan Beulich wrote: >>> On 09.10.2024 08:20, 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, its >>>> purpose is to pass the combination of compilation that CONFIG_XEN_PRIVCMD=y >>>> and CONFIG_XEN_PCIDEV_BACKEND=m, because in that combination, xen-pciback >>>> is compiled as a module but xen-privcmd is built-in, so xen-privcmd can't >>>> find the implementation of pcistub_get_gsi_from_sbdf. >>>> >>>> But that dependency causes xen-privcmd can't be loaded on domU, because >>>> dependent xen-pciback is always not be loaded successfully on domU. >>>> >>>> To solve above problem and cover original commit's requirement, just remove >>>> that dependency, because the code "IS_REACHABLE(CONFIG_XEN_PCIDEV_BACKEND)" >>>> of original commit is enough to meet the requirement. >>>> >>>> Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") >>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >>> >>> This lacks a Reported-by:. >>> >>>> --- a/drivers/xen/Kconfig >>>> +++ b/drivers/xen/Kconfig >>>> @@ -261,7 +261,6 @@ config XEN_SCSI_BACKEND >>>> config XEN_PRIVCMD >>>> tristate "Xen hypercall passthrough driver" >>>> depends on XEN >>>> - imply XEN_PCIDEV_BACKEND >>>> default m >>>> help >>>> The hypercall passthrough driver allows privileged user programs to >>> >>> The report wasn't about a build problem, but a runtime one. Removing the >>> dependency here doesn't change anything in the dependency of xen-privcmd >>> on xen-pciback, as the use of pcistub_get_gsi_from_sbdf() continues to >>> exist. >>> >>> Consider the case of XEN_PCIDEV_BACKEND=m and XEN_PRIVCMD=m, which >>> I guess is what Marek is using in his config. Both drivers are available >>> in such a configuration, yet loading of xen-privcmd then requires to >>> load xen-pciback first. And that latter load attempt will fail in a DomU. >>> The two drivers simply may not have any dependency in either direction. >> >> The idea is that there should be no hard dependency on >> pcistub_get_gsi_from_sbdf(). If it is available, the service will be >> used, otherwise an error will be reported. >> >> The problem is that IS_REACHABLE is a compile-time check. What we need >> is a runtime check instead. Maybe symbol_get or try_module_get ? > > This is a rather clumsy solution IMO. > > I'm seeing the following solutions: > > 1. Don't fail to to load the pciback driver in a DomU, but only disable > any functionality. > > 2. Move the drivers/xen/xen-pciback/pci_stub.c functionality in a module > of its own, allowing the privcmd driver to be loaded without needing > the rest of pciback. > > 3. Add a hook to e.g. drivers/xen/pci.c instead for calling of > pcistub_get_gsi_from_sbdf() directly. pciback could register the real > call address. If pciback isn't loaded, the hook can return an error. > This would remove the explicit dependency of privcmd on pciback. > > I'd prefer the 3rd variant. Thanks, I will send changes in v2 soon. And I prefer to add the hook in drivers/xen/acpi.c > > > Juergen >
On 10.10.24 09:07, Chen, Jiqian wrote: > On 2024/10/10 13:39, Jürgen Groß wrote: >> On 10.10.24 00:46, Stefano Stabellini wrote: >>> On Wed, 9 Oct 2024, Jan Beulich wrote: >>>> On 09.10.2024 08:20, 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, its >>>>> purpose is to pass the combination of compilation that CONFIG_XEN_PRIVCMD=y >>>>> and CONFIG_XEN_PCIDEV_BACKEND=m, because in that combination, xen-pciback >>>>> is compiled as a module but xen-privcmd is built-in, so xen-privcmd can't >>>>> find the implementation of pcistub_get_gsi_from_sbdf. >>>>> >>>>> But that dependency causes xen-privcmd can't be loaded on domU, because >>>>> dependent xen-pciback is always not be loaded successfully on domU. >>>>> >>>>> To solve above problem and cover original commit's requirement, just remove >>>>> that dependency, because the code "IS_REACHABLE(CONFIG_XEN_PCIDEV_BACKEND)" >>>>> of original commit is enough to meet the requirement. >>>>> >>>>> Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") >>>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >>>> >>>> This lacks a Reported-by:. >>>> >>>>> --- a/drivers/xen/Kconfig >>>>> +++ b/drivers/xen/Kconfig >>>>> @@ -261,7 +261,6 @@ config XEN_SCSI_BACKEND >>>>> config XEN_PRIVCMD >>>>> tristate "Xen hypercall passthrough driver" >>>>> depends on XEN >>>>> - imply XEN_PCIDEV_BACKEND >>>>> default m >>>>> help >>>>> The hypercall passthrough driver allows privileged user programs to >>>> >>>> The report wasn't about a build problem, but a runtime one. Removing the >>>> dependency here doesn't change anything in the dependency of xen-privcmd >>>> on xen-pciback, as the use of pcistub_get_gsi_from_sbdf() continues to >>>> exist. >>>> >>>> Consider the case of XEN_PCIDEV_BACKEND=m and XEN_PRIVCMD=m, which >>>> I guess is what Marek is using in his config. Both drivers are available >>>> in such a configuration, yet loading of xen-privcmd then requires to >>>> load xen-pciback first. And that latter load attempt will fail in a DomU. >>>> The two drivers simply may not have any dependency in either direction. >>> >>> The idea is that there should be no hard dependency on >>> pcistub_get_gsi_from_sbdf(). If it is available, the service will be >>> used, otherwise an error will be reported. >>> >>> The problem is that IS_REACHABLE is a compile-time check. What we need >>> is a runtime check instead. Maybe symbol_get or try_module_get ? >> >> This is a rather clumsy solution IMO. >> >> I'm seeing the following solutions: >> >> 1. Don't fail to to load the pciback driver in a DomU, but only disable >> any functionality. >> >> 2. Move the drivers/xen/xen-pciback/pci_stub.c functionality in a module >> of its own, allowing the privcmd driver to be loaded without needing >> the rest of pciback. >> >> 3. Add a hook to e.g. drivers/xen/pci.c instead for calling of >> pcistub_get_gsi_from_sbdf() directly. pciback could register the real >> call address. If pciback isn't loaded, the hook can return an error. >> This would remove the explicit dependency of privcmd on pciback. >> >> I'd prefer the 3rd variant. > Thanks, I will send changes in v2 soon. > And I prefer to add the hook in drivers/xen/acpi.c Agreed. Juergen
On 10.10.24 09:01, Jan Beulich wrote: > On 10.10.2024 07:39, Jürgen Groß wrote: >> On 10.10.24 00:46, Stefano Stabellini wrote: >>> On Wed, 9 Oct 2024, Jan Beulich wrote: >>>> On 09.10.2024 08:20, 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, its >>>>> purpose is to pass the combination of compilation that CONFIG_XEN_PRIVCMD=y >>>>> and CONFIG_XEN_PCIDEV_BACKEND=m, because in that combination, xen-pciback >>>>> is compiled as a module but xen-privcmd is built-in, so xen-privcmd can't >>>>> find the implementation of pcistub_get_gsi_from_sbdf. >>>>> >>>>> But that dependency causes xen-privcmd can't be loaded on domU, because >>>>> dependent xen-pciback is always not be loaded successfully on domU. >>>>> >>>>> To solve above problem and cover original commit's requirement, just remove >>>>> that dependency, because the code "IS_REACHABLE(CONFIG_XEN_PCIDEV_BACKEND)" >>>>> of original commit is enough to meet the requirement. >>>>> >>>>> Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") >>>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >>>> >>>> This lacks a Reported-by:. >>>> >>>>> --- a/drivers/xen/Kconfig >>>>> +++ b/drivers/xen/Kconfig >>>>> @@ -261,7 +261,6 @@ config XEN_SCSI_BACKEND >>>>> config XEN_PRIVCMD >>>>> tristate "Xen hypercall passthrough driver" >>>>> depends on XEN >>>>> - imply XEN_PCIDEV_BACKEND >>>>> default m >>>>> help >>>>> The hypercall passthrough driver allows privileged user programs to >>>> >>>> The report wasn't about a build problem, but a runtime one. Removing the >>>> dependency here doesn't change anything in the dependency of xen-privcmd >>>> on xen-pciback, as the use of pcistub_get_gsi_from_sbdf() continues to >>>> exist. >>>> >>>> Consider the case of XEN_PCIDEV_BACKEND=m and XEN_PRIVCMD=m, which >>>> I guess is what Marek is using in his config. Both drivers are available >>>> in such a configuration, yet loading of xen-privcmd then requires to >>>> load xen-pciback first. And that latter load attempt will fail in a DomU. >>>> The two drivers simply may not have any dependency in either direction. >>> >>> The idea is that there should be no hard dependency on >>> pcistub_get_gsi_from_sbdf(). If it is available, the service will be >>> used, otherwise an error will be reported. >>> >>> The problem is that IS_REACHABLE is a compile-time check. What we need >>> is a runtime check instead. Maybe symbol_get or try_module_get ? >> >> This is a rather clumsy solution IMO. >> >> I'm seeing the following solutions: >> >> 1. Don't fail to to load the pciback driver in a DomU, but only disable >> any functionality. >> >> 2. Move the drivers/xen/xen-pciback/pci_stub.c functionality in a module >> of its own, allowing the privcmd driver to be loaded without needing >> the rest of pciback. >> >> 3. Add a hook to e.g. drivers/xen/pci.c instead for calling of >> pcistub_get_gsi_from_sbdf() directly. pciback could register the real >> call address. If pciback isn't loaded, the hook can return an error. >> This would remove the explicit dependency of privcmd on pciback. >> >> I'd prefer the 3rd variant. > > Same here - order of preference backwards in the set presented above. > In the meantime the original change may simply need reverting? No, I don't think so. The breakage was introduced in 6.12 and we are still in the 6.12 rc phase. Standard Xen setups are running just fine, its just the Qubes use case which is broken. Having a fix in 6.12 should be enough. Juergen
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 72ddee4c1544..f7d6f47971fd 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -261,7 +261,6 @@ config XEN_SCSI_BACKEND config XEN_PRIVCMD tristate "Xen hypercall passthrough driver" depends on XEN - imply XEN_PCIDEV_BACKEND default m help The hypercall passthrough driver allows privileged user programs to
Commit 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") adds a weak reverse dependency to the config XEN_PRIVCMD definition, its purpose is to pass the combination of compilation that CONFIG_XEN_PRIVCMD=y and CONFIG_XEN_PCIDEV_BACKEND=m, because in that combination, xen-pciback is compiled as a module but xen-privcmd is built-in, so xen-privcmd can't find the implementation of pcistub_get_gsi_from_sbdf. But that dependency causes xen-privcmd can't be loaded on domU, because dependent xen-pciback is always not be loaded successfully on domU. To solve above problem and cover original commit's requirement, just remove that dependency, because the code "IS_REACHABLE(CONFIG_XEN_PCIDEV_BACKEND)" of original commit is enough to meet the requirement. Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> --- drivers/xen/Kconfig | 1 - 1 file changed, 1 deletion(-)