[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RESEND] Linux 2.3.23-rc3 on Xen 3.1 crashs


  • To: Bastian Blank <bastian@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Wed, 29 Aug 2007 15:22:34 +0100
  • Delivery-date: Wed, 29 Aug 2007 07:23:20 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfqSAqdSR3+lFY7EdyVXAAX8io7RQ==
  • Thread-topic: [Xen-devel] [RESEND] Linux 2.3.23-rc3 on Xen 3.1 crashs

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.