On 25.10.2023 14:49, Roger Pau Monné wrote: > On Thu, May 11, 2023 at 02:05:45PM +0200, Jan Beulich wrote: >> Somewhat like port CF9 this may have a bit controlling the CPU's INIT# >> signal, and it also may have a bit involved in the driving of A20M#. >> Neither of these - just like CF9 - we want to allow Dom0 to drive. >> >> Signed-off-by: Jan Beulich <[email protected]> > > Acked-by: Roger Pau Monné <[email protected]>
Thanks. > I'm kind of concerned that such ports might be used for other stuff > not described in the specifications I'm looking at, I guess we will > find out. There's a small risk, but there's also a certain risk from not making the port inaccessible. >> --- a/xen/arch/x86/dom0_build.c >> +++ b/xen/arch/x86/dom0_build.c >> @@ -500,6 +500,10 @@ int __init dom0_setup_permissions(struct >> rc |= ioports_deny_access(d, 0x40, 0x43); >> /* PIT Channel 2 / PC Speaker Control. */ >> rc |= ioports_deny_access(d, 0x61, 0x61); >> + >> + /* INIT# and alternative A20M# control. */ >> + rc |= ioports_deny_access(d, 0x92, 0x92); > > I do wonder whether it would make sense to create an array of [start, > end] IO ports to deny access to, so that we could loop over them and > code a single call to ioports_deny_access(). Maybe that's over > engineering it. It would compact part of the invocations, but some aren't using build- time constants, so wouldn't fit well with such a table approach. (I would probably ack a patch doing such a partial consolidation, but at least right now I don't think I would put time in making such a patch.) Jan
