On 08.12.20 15:33, Andrew Cooper wrote:
On 08/12/2020 13:51, Juergen Gross wrote:With CONFIG_PV_SHIM_EXCLUSIVE some sources required for CONFIG_HVM are not built, so let CONFIG_HVM depend on !CONFIG_PV_SHIM_EXCLUSIVE.Let CONFIG_HVM default to !CONFIG_PV_SHIM instead. Signed-off-by: Juergen Gross <[email protected]>So while this will fix the randconfig failure, the statement isn't true. There are HVM codepaths which aren't even dead in shim-exclusive mode.
I only said that CONFIG_PV_SHIM_EXCLUSIVE disables building some sources which are required for CONFIG_HVM, and this is certainly true.
The problem here is the way CONFIG_PV_SHIM_EXCLUSIVE abuses the Kconfig system. What is currently happening is that this option is trying to enforce the pv shim defconfig in the dependency system. We already have a defconfig, which is used in appropriate locations. We should not have two different things fighting over control. This is the fault of c/s 8b5b49ceb3d which went in despite my objections. The change is not related to PV_SHIM_EXCLUSIVE - it is to do with not supporting a control domain, which a) better describes what it is actually doing, and b) has wider utility than PV Shim.
Yes, maybe. Random build failures are not nice, so in case there is no agreement how to proceed I'd be in favor for fixing the fallout and then discuss a proper solution. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
