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

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

On Thu, Oct 26, 2023 at 05:07:18PM +0200, Jan Beulich wrote:
> On 26.10.2023 15:24, Roger Pau Monné wrote:
> > On Thu, Oct 26, 2023 at 11:03:42AM +0200, Jan Beulich wrote:
> >> On 26.10.2023 10:34, Roger Pau Monné wrote:
> >>> On Thu, May 11, 2023 at 02:06:46PM +0200, Jan Beulich wrote:
> >>>> ... in order to also deny Dom0 access through the alias ports. Without
> >>>> this it is only giving the impression of denying access to both PICs.
> >>>> Unlike for CMOS/RTC, do detection very early, to avoid disturbing normal
> >>>> operation later on.
> >>>>
> >>>> Like for CMOS/RTC a fundamental assumption of the probing is that reads
> >>>> from the probed alias port won't have side effects in case it does not
> >>>> alias the respective PIC's one.
> >>>
> >>> I'm slightly concerned about this probing.
> >>>
> >>> Also I'm unsure we can fully isolate the hardware domain like this.
> >>> Preventing access to the non-aliased ports is IMO helpful for domains
> >>> to realize the PIT is not available, but in any case such accesses
> >>> shouldn't happen in the first place, as dom0 must be modified to run
> >>> in such mode.
> >>
> >> That's true for PV Dom0, but not necessarily for PVH. Plus by denying
> >> access to the aliases we also guard against bugs in Dom0, if some
> >> component thinks there's something else at those ports (as they
> >> indeed were used for other purposes by various vendors).
> > 
> > I think it would be safe to add a command line option to disable the
> > probing, as we would at least like to avoid it in pvshim mode.  Maybe
> > ut would be interesting to make it a Kconfig option so that exclusive
> > pvshim Kconfig can avoid all this?
> > 
> > Otherwise it will just make booting the pvshim slower.
> 
> I've taken note to introduce such an option (not sure yet whether just
> cmdline or also Kconfig). Still
> - Shouldn't we already be bypassing related init logic in shim mode?

Not sure what we bypass in pvshim mode, would be good to double
check.

> - A Kconfig option interfacing with PV_SHIM_EXCLUSIVE will collide with
>   my patch inverting that option's sense (and renaming it), so it would
>   be nice to have that sorted/accepted first (see
>   https://lists.xen.org/archives/html/xen-devel/2023-03/msg00040.html).

It being Andrew the one that made the request, I would like to get his
opinion on it.  UNCONSTRAINED does seem a bit weird.

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.

Thanks, Roger.