Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.06.12 at 11:29, Alex Moskalenko <mav@xxxxxxxxx> wrote:
> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on 
> IBM eServer x3400. Without noacpi command line option dom0 kernel 
> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen 
> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor 
> all kernels run without any problems.

This is an issue that was reported and discussed previously.
Fundamentally, it is a firmware problem from my pov: ACPI has
_nothing_ to do with the MMIO space used for the IO-APICs of
the system once they are under control of the OS. It shouldn't
even be reading from them (which iirc was the case in earlier
reports), but in your case it looks like it's even writing them. I
had been considering to allow Dom0 read access to those pages,
but obviously this wouldn't help in your case.

Could you extract and supply the ACPI tables of that system, so
we can make an attempt at checking whether there is some reason
for the firmware writing to the IO-APIC that we didn't think of so
far?

> There are several patches (available on 
> http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=short 
> log;h=refs/heads/kernel-image-xen-dom0, 
> commits f1f91babc9cc9402ccee8938b888240f5bae1574, 
> 72db7b5e069002765ced64f030c1117d72352331, 
> adc4c567a08d4d2377060179639cbfdc3d9d8e0e and 
> 9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32 to 
> boot on this hardware. This patches written by kernel package maintainer 

While they could make an attempt at upstreaming them, I don't
think the way this is being dealt with (altering the set_pte() and
set_pte_at() return types) would be well received. (The Xen-
specific adjustments look bogus altogether, btw.)

> of ALT Linux distribution. Discussion of this issue is available on 
> Sysadmins ALTLinux mailing list 
> (http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html 
> and follows) in Russian.

But there's no real analysis of the underlying problem there.
Perhaps the author of the patches should have turned here?

(As a side note - non-pvops Xen wouldn't have this problem, as
the hypercalls underlying ioremap() get properly error-checked
there, and result in the ioremap() failing rather than a #PF
getting raised.)

Jan

> I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need this 
> messages for more recent versions of Xen and kernel, or more information 
> about hardware, please let me know.
> 
> Ideally, I would like to run current versions of Xen and Linux kernels 
> on this hardware. Can you help me please?
> 
> 
> --
>   WBR, Alex Moskalenko




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