Re: [PATCH 4/7] x86: detect PIC aliasing on ports other than 0x[2A][01]

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Oct 30, 2023 at 04:35:41PM +0100, Jan Beulich wrote:
> On 30.10.2023 16:23, Roger Pau Monné wrote:
> > On Mon, Oct 30, 2023 at 04:19:22PM +0100, Jan Beulich wrote:
> >> On 30.10.2023 16:14, Roger Pau Monné wrote:
> >>> On Mon, Oct 30, 2023 at 01:24:52PM +0100, Jan Beulich wrote:
> >>>> On 26.10.2023 17:19, Roger Pau Monné wrote:
> >>>>> Maybe the issue is that PV_SHIM_EXCLUSIVE shouldn't have been a
> >>>>> Kconfig option in the first place, and instead a specific Kconfig
> >>>>> config file?
> >>>>>
> >>>>> Maybe it's not possible to achieve the same using just a Kconfig
> >>>>> config file.
> >>>>
> >>>> I'm afraid I don't understand what you mean by "Kconfig config file". It
> >>>> can't really be just another .../Kconfig file somewhere in the tree, as
> >>>> it doesn't really matter where an option like this would be defined.
> >>>
> >>> No, I was thinking of splitting what PV_SHIM_EXCLUSIVE actually
> >>> implies, for example by adding CONFIG_DOMCTL_HYPERCALLL or
> >>> CONFIG_PLATFORM_HYPERCALL and re-work the pvshim_defconfig config file
> >>> based on those, so that we don't end up with negative relations.
> >>>
> >>> Note sure all usages of PV_SHIM_EXCLUSIVE can be split in such a way,
> >>> maybe we would need some compromise.
> >>
> >> Wouldn't such a CONFIG_DOMCTL_HYPERCALL then still want to depend on
> >> !PV_SHIM_EXCLUSIVE, which is the kind of dependency we want to avoid?
> >> Aiui the two (splitting and inverting) are largely orthogonal aspects.
> > 
> > No, CONFIG_DOMCTL_HYPERCALL could be promptless option enabled by
> > default and disabled by the pvshim_defconfig.
> 
> pvshim_defconfig shouldn't play a role here. Anyone configuring a shim
> build from scratch should also get a consistent set of settings.

Then we might have to expose those more fine grained options.

My sauggestion was to still allow enabling shim mode from by the user,
but that building a pv-shim exclusive image would require using the
pvshim_defconfig, to simply avoid exposing a bunch of fine grained
options that only make sense for pv-shim exclusive builds.

If that's not sensible, we might consider exposing those more fine
grained options.

Thanks, Roger.