[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen: CONFIG_PV_SHIM_EXCLUSIVE and CONFIG_HVM are mutually exclusive



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 <jgross@xxxxxxxx>

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

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.