This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] FW: [Xen-users] Re: Squeeze and Xen 4 - booting error wh

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