On Thu, May 11, 2023 at 02:08:09PM +0200, Jan Beulich wrote: > Much like the other PIC ports, Dom0 has no business touching these. Even > our own uses are somewhat questionable, as the corresponding IO-APIC > code in Linux is enclosed in a CONFIG_EISA conditional; I don't think > there are any x86-64 EISA systems. > > Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Roger Pau Monné <[email protected]> > --- > RFC: For Linux'es (matching our) construct_default_ioirq_mptable() we > may need to permit read access at least for PVH, if such default > table construction is assumed to be sensible there in the first > place (we assume ACPI and no PIC for PVH Dom0, after all). Unless I'm confused, thise ports only control the triggering mode of the PICs, and hence a PVH dom0 should have no business with them, as not having a PIC in the first place. > > RFC: Linux further has ACPI boot code accessing ELCR > (acpi_pic_sci_set_trigger() and acpi_register_gsi_pic()), which we > have no equivalent of. If access to the port is denied, ~0 will be returned, and hence all IRQs will be assumed to be level. Some bits reserved and must be 0 will also be returned as 1. > > Taken together, perhaps the hiding needs to be limited to PVH Dom0? I very much doubt Xen will ever use the PIC unless forced on the command line, and we should likely remove such option and just mandate a working IO-APIC in order to run Xen. My only doubt is whether some Linux code will get confused by poking at ELCR{1,2} and malfunction as a result of not being able to fetch a sane mask. As a last resort, we could make the register RO? Thanks, Roger.
