[Xen-devel] IO-APIC pages being accessed by ACPI methods

["Jan Beulich" <JBeulich@xxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel