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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.03.13 at 13:51, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Tue, Mar 12, 2013 at 10:00:08AM +0000, Jan Beulich wrote:
>> 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 recall a couple, but I can't tell whether they weren't all with the
same or similar hardware. Some may pre-date your working on
Xen though.

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

As said - by virtue of the MTRRs being set up right, this works in
general. But I do indeed think that this is a latent bug in the ACPICA
glue code (the more considering that it's supposed to be arch
invariant, yet non-x86 platforms don't necessarily have concepts
similar to x86's MTRRs).

> Or by cachable mappings you mean WB?

Yes, that's the main kind of caching done these days (who cares
about WT)? And to avoid misunderstanding - WC to me is not
really a cachable memory type, and ACPICA doesn't use it.

Jan


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