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: Bastian Blank <bastian@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
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 15:22:34 +0100
Delivery-date: Wed, 29 Aug 2007 07:23:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070829141307.GA9199@xxxxxxxxxxxxxxxxxxxxxxx>
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: AcfqSAqdSR3+lFY7EdyVXAAX8io7RQ==
Thread-topic: [Xen-devel] [RESEND] Linux 2.3.23-rc3 on Xen 3.1 crashs
User-agent: Microsoft-Entourage/
On 29/8/07 15:13, "Bastian Blank" <bastian@xxxxxxxxxxxx> wrote:

> On Wed, Aug 29, 2007 at 02:09:23PM +0100, Keir Fraser wrote:
>> 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.
> What should happen with the upcoming MCE support in Xen?

We'll cross that bridge when we come to it. ;-) The default will be that it
all continues to be handled by Xen, and explicit paravirtualisations will be
introduced to allow dom0, and perhaps domUs also, to get involved.

>> 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.
> What is the documented behaviour if a bit is set while the machine lacks
> support for it?

That should GPF. But no OS actually probes for features that way, as there
are perfectly good CPUID feature flags for that. Linux in particular will
not be happy if any of its writes to CR4 results in a GPF.

 -- Keir

Xen-devel mailing list