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.
