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

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

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