Re: IO-APIC pages being accessed by ACPI methods

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 12/03/13 10:00, Jan Beulich wrote:
> All,
>
> considering the non-negligible number of systems where firmware
> has ACPI methods that reference IO-APIC pages (causing
> method execution to fail on non-pvops Dom0, and crashing pvops),
> I'm wondering whether we shouldn't relax treatment of IO-APIC
> MMIO space by moving it from the completely access denied state
> that it's currently in (due to construct_dom0() having
>
>     /* I/O APICs. */
>     for ( i = 0; i < nr_ioapics; i++ )
>     {
>         mfn = paddr_to_pfn(mp_ioapics[i].mpc_apicaddr);
>         if ( smp_found_config )
>             rc |= iomem_deny_access(dom0, mfn, mfn);
>     }
>
> ) to allowing read access, and dropping writes (through the MMIO
> R/O emulation added for specific PCI devices during 4.2
> development).
>
> Afaict this ought to be safe, as no reads of currently defined
> IO-APIC registers have side effects. But of course we don't know
> what extensions there might be to come.
>
> If we do so (and perhaps even independently of this) we probably
> ought to enforce consistent cachability attributes on the secondary
> mappings Dom0 then is able to establish - either by further
> modifying the requested flags, or by outright denying mapping
> requests that aren't specifying UC. While the latter would be my
> preference and would work for the MMCFG case, the ACPI case
> described here wouldn't be covered - Linux'es ACPICA creates
> cachable mappings regardless of whether a SystemMemory is
> RAM or MMIO (thus risking problems even on native).
>
> Opinions appreciated,
> Jan

How likely is it for the IO-APIC to change? It is needed for legacy
reasons but I cant see it changing much in the future.  We have even
been at the same "latest version" for a long time now.

If no registers currently have read side-effects (I have just checked
the latest reference I can find and cant spot any side-effects), and it
solves failure/crash situations on some hardware, I would vote in favor
of such a system.

If however we do find a system in the future which has read
side-effects, we could possibly degrade a read mapping to
trap-and-emulate for safety.

Purely a nit - the name "iomem_deny_access" is confusing for a function
which adds a RO mapping to a domain.  I realize it got this name based
on its first use (changing RW PCI mappings to RO), but it might be
prudent to rename it to something such as "iomem_ro_mapping" or so.

~Andrew