WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] First release candidate for 3.2.0

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] First release candidate for 3.2.0
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Tue, 11 Dec 2007 03:42:37 +0000
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 10 Dec 2007 19:43:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C382CEF9.19A39%keir.fraser@xxxxxxxxxxxxx>
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>
References: <C382CEF9.19A39%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Mon, Dec 10, 2007 at 11:09:45AM +0000, Keir Fraser wrote:

> The first release candidate for Xen 3.2.0 is available at
> http://xenbits.xensource.com/xen-unstable.hg, tagged as '3.2.0-rc1'.

I used current tip instead. This was the first time we've run Solaris
past 3.1*. As expected the results were not good.

There's some terrible nastiness in the rdmsr emulation path:

(XEN) traps.c:2046:d0 Domain attempted RDMSR 000000000000008b ret to EIP 
fffffffffb85a0d4 ESP fffffffffbc7b408.
(XEN) traps.c:2053:d0 succeeded, eax now 000000000000003a, edx now 
0000000000000000
(XEN) traps.c:2061:d0 value at rsp was fffffffffb82acde now fffffffffb82acde
(XEN) traps.c:2046:d0 Domain attempted RDMSR 00000000c0010015 ret to EIP 
fffffffffb85a0d4 ESP fffffffffbc7b408.
(XEN) traps.c:2053:d0 succeeded, eax now 0000000010000040, edx now 
0000000000000000
(XEN) traps.c:2061:d0 value at rsp was fffffffffb82acde now fffffffffb82acde
panic[cpu0]/thread=fffffffffbc48da0: BAD TRAP: type=e (#pf Page fault) 
rp=fffffffffbc7b320 addr=10000040 occurred in module "unix" due to a NULL 
pointer dereference

#pf Page fault
Bad kernel fault at addr=0x10000040

Something has been spewing zeroes all over our text:

checked_rdmsr:                  pushq  %rbp
checked_rdmsr+1:                movq   %rsp,%rbp
checked_rdmsr+4:                subq   $0x18,%rsp
checked_rdmsr+8:                pushq  %r12
checked_rdmsr+0xa:              movq   %rdi,-0x8(%rbp)
checked_rdmsr+0xe:              movq   %rsi,-0x10(%rbp)
checked_rdmsr+0x12:             movq   %rsi,%r12
checked_rdmsr+0x15:             cmpl   $0x0,+0x434218(%rip)     <disable_msrs>
checked_rdmsr+0x1c:             jne    +0x18    <checked_rdmsr+0x36>
checked_rdmsr+0x1e:             movl   +0x3d62fc(%rip),%eax     <x86_feature>
checked_rdmsr+0x24:             andl   $0x4,%eax
checked_rdmsr+0x27:             je     +0xd     <checked_rdmsr+0x36>
checked_rdmsr+0x29:             call   +0x2f3f2 <rdmsr>
checked_rdmsr+0x2e:             addb   %al,(%rax)
checked_rdmsr+0x30:             .byte   0
checked_rdmsr+0x31:             .byte   0
checked_rdmsr+0x32:             .byte   0
checked_rdmsr+0x33:             .byte   0
checked_rdmsr+0x34:             .byte   0
checked_rdmsr+0x35:             .byte   0
checked_rdmsr+0x36:             .byte   0
checked_rdmsr+0x37:             .byte   0
checked_rdmsr+0x38:             .byte   0
checked_rdmsr+0x39:             .byte   0
checked_rdmsr+0x3a:             .byte   0
checked_rdmsr+0x3b:             .byte   0
checked_rdmsr+0x3c:             .byte   0
checked_rdmsr+0x3d:             .byte   0
checked_rdmsr+0x3e:             ret

[0]> rdmsr::dis
rdmsr:                          movl   %edi,%ecx
rdmsr+2:                        rdmsr
rdmsr+4:                        shlq   $0x20,%rdx
rdmsr+8:                        orq    %rdx,%rax
rdmsr+0xb:                      ret

So, it's possible that we have somehow mangled things, but also quite unlikely
- this is based on code that works with 3.1.0. If I set 'disable_msrs', then I
get much further in Solaris boot until we die with a corrupted mutex.

I've had a look through changes in entry.S but I can't really make much sense
of them (I never can). I tried backing out Jan's sysenter changes, as they 
looked scary, but that didn't seem to help.

The only thing that comes to mind is somewhere the "disables_events" path got
broken again - any ideas Keir? Unfortunately I only have a limited time to look
at this as I'm focused on finishing up 3.1 now.

regards
john

* keeping dom0 up to date is a thankless task

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel