Re: IO-APIC pages being accessed by ACPI methods

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Mar 12, 2013 at 10:00:08AM +0000, 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),

Hmm. I recall only seeing one issue on xen-devel with an IBM box.
Were there more?

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

Eww. That looks like a bug in the ACPICA? Perhaps my recollection
is incorrect but shouldn't MMIO regions mostly be UC. Only drivers
that know what they are doing (say graphic cards) can choose to
set that to WC?

Or by cachable mappings you mean WB?
> 
> Opinions appreciated,
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>