Re: [PATCH 7/7] x86: don't allow Dom0 access to ELCR ports

["Roger Pau Monné" <roger.pau@citrix.com>]

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 <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

> ---
> 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.