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
|
Home