>>> On 16.03.11 at 04:24, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Mon, Mar 14, 2011 at 03:51:08PM -0700, Paul Wozney wrote:
>> On Mon, Mar 14, 2011 at 04:49, Pasi Kärkkäinen <pasik@xxxxxx> wrote:
>> > Did he try booting the latest dom0 kernel from xen.git xen/stable-2.6.32.x
>> > branch?
>> I compiled this kernel and I get a different kernel panic.
> What type of config did you use? Did you try the one in PVOPS Wiki page?
> Is this happening only on this specific machine?
> What does your DSDT look like? Can you run iasl on it to decompile?
> This looks like a bug we hit in the past where Jan Beulich decoded
> the DSDT and found out that it was doing somethign really silly.
> Can't remember the details .. maybe Jan does.
Yes, it very much looks like that. The problem was that some
method in the DSDT tried to access a field in the IO-APIC's MMIO
range, but that range isn't available to any domain (including
On non-pvops, and ioremap() attempt like this will simply fail, but
on pv-ops (using native's set_pte_at(), which has no return
value) the attempt to establish the page table entry will simply
fault, leading to a kernel panic in cases like this.
Of course it is bogus for the firmware to have an ACPI method
access IO-APIC space - that should be under the exclusive
control of the OS (and hence your first and best option is to
obtain fixed firmware).
Nevertheless, if this was just a read (don't recall whether it was
in the original case), it would seem possible to allow this,
utilizing the mmio_ro_ranges functionality introduced for MSI-X's
table and PBA.
One problem with this is that it could have bad effects in terms
of hiding future latent kernel bugs in that the actual IO-APIC
handling code might wrongly establish a mapping of the real
IO-APIC page - in this context, outright failing the mapping
attempt is certainly better than silently converting a writeable
mapping to a read-only one. But obviously Xen can't distinguish
one from the other.
Xen-devel mailing list