On 29.09.2021 13:56, Oleksandr Andrushchenko wrote: > > On 29.09.21 12:09, Jan Beulich wrote: >> On 29.09.2021 11:03, Oleksandr Andrushchenko wrote: >>> Sorry for top posting, but this is a general question on this >>> patch/functionality. >>> >>> Do you see we need to gate all this with CONFIG_HAS_VPCI_GUEST_SUPPORT >>> as this renders in somewhat dead code for x86 for now? I do think this still >>> needs to be in the common code though. >> I agree it wants to live in common code, but I'd still like the code to >> not bloat x86 binaries. Hence yes, I think there want to be >> "if ( !IS_ENABLED() )" early bailout paths or, whenever this isn't >> possible without breaking the build, respective #ifdef-s. > > Then it needs to be defined as (xen/drivers/Kconfig): > > config HAS_VPCI_GUEST_SUPPORT > # vPCI guest support is only enabled for Arm now > def_bool y if ARM > depends on HAS_VPCI > > Because it needs to be defined as "y" for Arm with vPCI support. > > Otherwise it breaks the PCI passthrough feature, e.g. it compiles, > > but the resulting binary behaves wrong. > > Do you see this as an acceptable solution?
Like all (or at least the majority) of other HAS_*, it ought to be "select"-ed (by arm/Kconfig). Is there a reason this isn't possible? (I don't mind the "depends on", as long as it's clear that it exists solely to allow kconfig to warn about bogus "select"s.) Jan
