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] [RESEND] Linux 2.3.23-rc3 on Xen 3.1 crashs

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Bastian Blank <bastian@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RESEND] Linux 2.3.23-rc3 on Xen 3.1 crashs
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 29 Aug 2007 14:09:23 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 29 Aug 2007 06:10:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46D57550.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfqPdFgD62f31YxEdyVXAAX8io7RQ==
Thread-topic: [Xen-devel] [RESEND] Linux 2.3.23-rc3 on Xen 3.1 crashs
User-agent: Microsoft-Entourage/
Sounds like Bastian already worked out the problem is we do not allow
X86_CR4_MCE to be cleared. Xen should probably just ignore attempts to
change that bit. Even better would be to remember guest value of that flag
and return appropriate value on reads of CR4. But that's more than required
here, I think.

Actually, instead of GPF'ing on 'bad' CR4 writes, we could just log a
XENLOG_WARNING and return. That would avoid any problems for any other CR4
bits too.

 -- Keir

On 29/8/07 12:32, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>>>> Bastian Blank <bastian@xxxxxxxxxxxx> 29.08.07 13:02 >>>
>> On Wed, Aug 29, 2007 at 11:39:25AM +0100, Jan Beulich wrote:
>>> These aren't really meaningful, as the VM was obviously in a loop getting
>>> repeated exceptions (and the stack pointer clearly went bad meanwhile).
>>> You'd need to catch the state much earlier, when the first (or just very
>>> few)
>>> of these exceptions happened, so that looking at the stack can actually
>>> provide some insight.
>> How? There seems to be something in tools/debugger/gdb. It seems to
>> build a special gdbserver. Does this gdbserver stop the domain on an
>> exception or do I need to break explicitely?
> I never used it, so I don't know. But you must have been building the kernel
> yourself, and given from you testing -rc kernels I also assume you're familiar
> with modifying the kernel sources, so it shouldn't be too difficult to e.g.
> remove registration of the illegal opcode handler so that Xen dumps the
> VCPU state (and kills the VM) the first time such an exception occurs in the
> guest (of course assuming there are no other instances of 'valid' uses of
> the exception - you'd see this pretty quickly).
> Jan
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list