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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

Is Solaris easy to grab and build, or does it need a Solaris environment?
Alternatively, can I grab a pre-built binary (with symbols) from somewhere?

 -- Keir

On 11/12/07 03:42, "John Levon" <levon@xxxxxxxxxxxxxxxxx> wrote:

> 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



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