From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: FW: [Xen-users] Re: Squeeze and Xen 4 - booting error when loading xen-hypervisor-4.0-amd64 Date: Wed, 16 Mar 2011 08:38:46 +0000 Message-ID: <4D8085260200007800036C29@vpn.id2.novell.com> References: <20110314114936.GF32595@reaktio.net> <20110316032431.GD7905@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20110316032431.GD7905@dumpdata.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk , Paul Wozney Cc: xen-devel@lists.xensource.com, Mike Viau List-Id: xen-devel@lists.xenproject.org >>> On 16.03.11 at 04:24, Konrad Rzeszutek Wilk = wrote: > On Mon, Mar 14, 2011 at 03:51:08PM -0700, Paul Wozney wrote: >> On Mon, Mar 14, 2011 at 04:49, Pasi K=C3=A4rkk=C3=A4inen wrote: >>=20 >> > >> > Did he try booting the latest dom0 kernel from xen.git xen/stable-2.= 6.32.x >> > branch? >> > >>=20 >> I compiled this kernel and I get a different kernel panic. >=20 > What type of config did you use? Did you try the one in PVOPS Wiki page= ? >=20 > Is this happening only on this specific machine? >=20 > What does your DSDT look like? Can you run iasl on it to decompile? >=20 > 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 Dom0). 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. Jan