Using SYSCALL/SYSRET with a minios kernel

Using SYSCALL/SYSRET with a minios kernel

[Goswin von Brederlow]

Hi,

I'm trying to use the SYSCALL/SYSRET opcodes with a minios kernel
without much success.

Going by the manuals (and linux sources) I first have to setup the
STAR and LSTAR registers to define the segment and instruction pointer
to be used for SYSCALL:

	/* 
         * LSTAR and STAR live in a bit strange symbiosis.
         * They both write to the same internal register. STAR allows to set
         * CS/DS but only a 32bit target. LSTAR sets the 64bit rip.
         */ 
        wrmsrl(MSR_STAR,  ((uint64_t)__USER_CS)<<48  | ((uint64_t)__KERNEL_CS)<<32); 
        wrmsrl(MSR_LSTAR, system_call); 


But all that does is give a message on the xen console:

(XEN) traps.c:1467:d137 Domain attempted WRMSR 00000000c0000081 from e023e010:00000000 to e033e033:00000000.
(XEN) traps.c:1467:d137 Domain attempted WRMSR 00000000c0000082 from ffff8300:001e0800 to 00000000:001054c0.


A later
	__asm__ __volatile__("syscall"::);
does nothing while a
	__asm__ __volatile__("sysret"::);
causes a general protection fault:

(XEN) traps.c:405:d137 Unhandled general protection fault fault/trap [#13] in domain 137 on VCPU 0 [ec=0000]
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 137 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.0.4-1  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[<000000000010559f>]
(XEN) RFLAGS: 0000000000000216   CONTEXT: guest
(XEN) rax: fffffffffffffff2   rbx: 0000000001857000   rcx: 000000000010559f
(XEN) rdx: 0000000000000100   rsi: 00000000deadbeef   rdi: 00000000deadbeef
(XEN) rbp: 0000000000000000   rsp: 0000000000108310   r8:  00000000001ff000
(XEN) r9:  0000000001857000   r10: 00000000fffffff9   r11: 0000000000000216
(XEN) r12: 0000000001851000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) cr3: 00000000268f8000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=0000000000108310:
(XEN)    000000000010559f 0000000000000216 0000000000000000 000000000010559f
(XEN)    000000000000e030 0000000000010216 0000000000108350 000000000000e02b
(XEN)    0000000000000000 0000000000119000 0000000000000000 00000000001040ba
(XEN)    6f622065736f6f4d 2e2e2e676e69746f 0000000000000a0d 0000000000000000
(XEN)    61727473746f6f42 2e2e2e676e697070 000000000000000a 0000000000000000
(XEN)    0000000000000000 0000000000100010 0000000000119000 0000000000113000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000

Any pointers would be welcome.

MfG
        Goswin

Re: Using SYSCALL/SYSRET with a minios kernel

[Daniel Stodden]

Hi.

On Mon, 2008-02-25 at 00:22 +0100, Goswin von Brederlow wrote: 
> Hi,
> 
> I'm trying to use the SYSCALL/SYSRET opcodes with a minios kernel
> without much success.
> 
> Going by the manuals (and linux sources) I first have to setup the
> STAR and LSTAR registers to define the segment and instruction pointer
> to be used for SYSCALL:
> 
> 	/* 
>          * LSTAR and STAR live in a bit strange symbiosis.
>          * They both write to the same internal register. STAR allows to set
>          * CS/DS but only a 32bit target. LSTAR sets the 64bit rip.
>          */ 
>         wrmsrl(MSR_STAR,  ((uint64_t)__USER_CS)<<48  | ((uint64_t)__KERNEL_CS)<<32); 
>         wrmsrl(MSR_LSTAR, system_call); 
> 
> 
> But all that does is give a message on the xen console:
> 
> (XEN) traps.c:1467:d137 Domain attempted WRMSR 00000000c0000081 from e023e010:00000000 to e033e033:00000000.
> (XEN) traps.c:1467:d137 Domain attempted WRMSR 00000000c0000082 from ffff8300:001e0800 to 00000000:001054c0.

The PV interface simply does not support STAR/LSTAR. It's that
simple. :) I suppose you want to implement system calls? Check the
HYPERVISOR_set_callbacks() call. The syscall_address parameter presently
remains entirely unused in mini-os. But as far as I could tell
immediately from the source, syscall/sysret appears to be supported by
the general callback mechanism the same way sysenter/sysleave presently
is.

regards,
daniel


-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B

Re: Using SYSCALL/SYSRET with a minios kernel

[Goswin von Brederlow]

Daniel Stodden <stodden@cs.tum.edu> writes:

> Hi.
>
> On Mon, 2008-02-25 at 00:22 +0100, Goswin von Brederlow wrote: 
>> Hi,
>> 
>> I'm trying to use the SYSCALL/SYSRET opcodes with a minios kernel
>> without much success.
>...
> The PV interface simply does not support STAR/LSTAR. It's that
> simple. :) I suppose you want to implement system calls? Check the
> HYPERVISOR_set_callbacks() call. The syscall_address parameter presently
> remains entirely unused in mini-os. But as far as I could tell
> immediately from the source, syscall/sysret appears to be supported by
> the general callback mechanism the same way sysenter/sysleave presently
> is.
>
> regards,
> daniel

Ok, here is what I did for the callbacks:

--- x86_64.S ---
ENTRY(syscall_callback)
	int $80
	zeroentry do_syscall

--- kernel.c ---
  HYPERVISOR_set_callbacks((unsigned long)hypervisor_callback,
			   (unsigned long)failsafe_callback,
			   (unsigned long)syscall_callback);

  __asm__ __volatile__("syscall");

If I understood you right that should set the RIP to syscall_callback
and execute from there. But still, the syscall opcode does nothing.
In case you wonder. The "int $80" is there to crash the domain and
tell me it reached that point.

MfG
        Goswin

Re: Using SYSCALL/SYSRET with a minios kernel

[Daniel Stodden]

On Mon, 2008-02-25 at 02:55 +0100, Goswin von Brederlow wrote:
> Daniel Stodden <stodden@cs.tum.edu> writes:
> 
> > Hi.
> >
> > On Mon, 2008-02-25 at 00:22 +0100, Goswin von Brederlow wrote: 
> >> Hi,
> >> 
> >> I'm trying to use the SYSCALL/SYSRET opcodes with a minios kernel
> >> without much success.
> >...
> > The PV interface simply does not support STAR/LSTAR. It's that
> > simple. :) I suppose you want to implement system calls? Check the
> > HYPERVISOR_set_callbacks() call. The syscall_address parameter presently
> > remains entirely unused in mini-os. But as far as I could tell
> > immediately from the source, syscall/sysret appears to be supported by
> > the general callback mechanism the same way sysenter/sysleave presently
> > is.
> >
> > regards,
> > daniel
> 
> Ok, here is what I did for the callbacks:
> 
> --- x86_64.S ---
> ENTRY(syscall_callback)
> 	int $80
> 	zeroentry do_syscall
> 
> --- kernel.c ---
>   HYPERVISOR_set_callbacks((unsigned long)hypervisor_callback,
> 			   (unsigned long)failsafe_callback,
> 			   (unsigned long)syscall_callback);
> 
>   __asm__ __volatile__("syscall");
> 
> If I understood you right that should set the RIP to syscall_callback
> and execute from there.

Mööp! Only when calling in from virtual user mode. Otherwise, you're
triggering a hypercall service routine, and one might suspect you're
presently just generating an error condition with that. :)

BTW: I found building Xen with 'debug=y' generates a helpful comment on
the console every now and xen.

> But still, the syscall opcode does nothing.
> In case you wonder. The "int $80" is there to crash the domain and
> tell me it reached that point.

hth,
daniel

-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B

Re: Using SYSCALL/SYSRET with a minios kernel

[Goswin von Brederlow]

Daniel Stodden <stodden@cs.tum.edu> writes:

> On Mon, 2008-02-25 at 02:55 +0100, Goswin von Brederlow wrote:
>> Daniel Stodden <stodden@cs.tum.edu> writes:
>> 
>> > Hi.
>> >
>> > On Mon, 2008-02-25 at 00:22 +0100, Goswin von Brederlow wrote: 
>> >> Hi,
>> >> 
>> >> I'm trying to use the SYSCALL/SYSRET opcodes with a minios kernel
>> >> without much success.
>> >...
>> > The PV interface simply does not support STAR/LSTAR. It's that
>> > simple. :) I suppose you want to implement system calls? Check the
>> > HYPERVISOR_set_callbacks() call. The syscall_address parameter presently
>> > remains entirely unused in mini-os. But as far as I could tell
>> > immediately from the source, syscall/sysret appears to be supported by
>> > the general callback mechanism the same way sysenter/sysleave presently
>> > is.
>> >
>> > regards,
>> > daniel
>> 
>> Ok, here is what I did for the callbacks:
>> 
>> --- x86_64.S ---
>> ENTRY(syscall_callback)
>> 	int $80
>> 	zeroentry do_syscall
>> 
>> --- kernel.c ---
>>   HYPERVISOR_set_callbacks((unsigned long)hypervisor_callback,
>> 			   (unsigned long)failsafe_callback,
>> 			   (unsigned long)syscall_callback);
>> 
>>   __asm__ __volatile__("syscall");
>> 
>> If I understood you right that should set the RIP to syscall_callback
>> and execute from there.
>
> Mööp! Only when calling in from virtual user mode. Otherwise, you're
> triggering a hypercall service routine, and one might suspect you're
> presently just generating an error condition with that. :)

That sounds verry odd. I'm getting no indication of it from xen.

But ok. How do I test that. Or differently phrased: What is the best
way to go into user space for the verry first time? Do I really have
to create a fake stack frame and call HYPERVISOR_iret?

> BTW: I found building Xen with 'debug=y' generates a helpful comment on
> the console every now and xen.

I did that and added a patch that makes HYPERVISOR_console_io work for
domU so it shows up in "xm dmesg".

>> But still, the syscall opcode does nothing.
>> In case you wonder. The "int $80" is there to crash the domain and
>> tell me it reached that point.
>
> hth,
> daniel

MfG
        Goswin

Re: Using SYSCALL/SYSRET with a minios kernel

[Daniel Stodden]

On Mon, 2008-02-25 at 11:04 +0100, Goswin von Brederlow wrote:

> >> --- kernel.c ---
> >>   HYPERVISOR_set_callbacks((unsigned long)hypervisor_callback,
> >> 			   (unsigned long)failsafe_callback,
> >> 			   (unsigned long)syscall_callback);
> >> 
> >>   __asm__ __volatile__("syscall");
> >> 
> >> If I understood you right that should set the RIP to syscall_callback
> >> and execute from there.
> >
> > Mööp! Only when calling in from virtual user mode. Otherwise, you're
> > triggering a hypercall service routine, and one might suspect you're
> > presently just generating an error condition with that. :)
> 
> That sounds verry odd. I'm getting no indication of it from xen.

Why odd? That's how e.g. syscall processing in Xen's entry.S is structured.
Many hypercalls fail with messages. But e.g. an invalid hypercall number
would silently return -ENOSYS, so it does not appear too unlikely. 
What do you get instead?

> But ok. How do I test that. Or differently phrased: What is the best
> way to go into user space for the verry first time? Do I really have
> to create a fake stack frame and call HYPERVISOR_iret?

iret is the only method I am aware of, can't think about anything else. Doubt
that a stack switch would be forcibly required.

Does not neccesarily mean much, however, since I did not write the freaky thing.

> > BTW: I found building Xen with 'debug=y' generates a helpful comment on
> > the console every now and xen.
> 
> I did that and added a patch that makes HYPERVISOR_console_io work for
> domU so it shows up in "xm dmesg".

Ah, I see. Good idea.

> >> But still, the syscall opcode does nothing.
> >> In case you wonder. The "int $80" is there to crash the domain and
> >> tell me it reached that point.

Shouldn't that just get you a GPF? 

regards,
Daniel


-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B

Re: Using SYSCALL/SYSRET with a minios kernel

[Goswin von Brederlow]

Daniel Stodden <stodden@cs.tum.edu> writes:

> On Mon, 2008-02-25 at 11:04 +0100, Goswin von Brederlow wrote:
>
>> >> --- kernel.c ---
>> >>   HYPERVISOR_set_callbacks((unsigned long)hypervisor_callback,
>> >> 			   (unsigned long)failsafe_callback,
>> >> 			   (unsigned long)syscall_callback);
>> >> 
>> >>   __asm__ __volatile__("syscall");
>> >> 
>> >> If I understood you right that should set the RIP to syscall_callback
>> >> and execute from there.
>> >
>> > Mööp! Only when calling in from virtual user mode. Otherwise, you're
>> > triggering a hypercall service routine, and one might suspect you're
>> > presently just generating an error condition with that. :)
>> 
>> That sounds verry odd. I'm getting no indication of it from xen.
>
> Why odd? That's how e.g. syscall processing in Xen's entry.S is structured.
> Many hypercalls fail with messages. But e.g. an invalid hypercall number
> would silently return -ENOSYS, so it does not appear too unlikely. 
> What do you get instead?

Nothing. The 'syscall' instruction behaves like a 'nop'. If Xen's
syscall emulation fails then I would expect it to raise some
exception, e.g. illegal instruction.

The amd64 tech docs indicate that syscall can be used recursively
(indicated by SS == 0) and no check on the CPL is performed by
'syscall'. So I would expect that i could call 'syscall' even in
kernel mode in Xen too. But now that I know better that is ok too.

>> But ok. How do I test that. Or differently phrased: What is the best
>> way to go into user space for the verry first time? Do I really have
>> to create a fake stack frame and call HYPERVISOR_iret?
>
> iret is the only method I am aware of, can't think about anything else. Doubt
> that a stack switch would be forcibly required.
>
> Does not neccesarily mean much, however, since I did not write the freaky thing.

I added the following code to x86_64.S:

ENTRY(fail)
        syscall
        int $3
        jmp fail
        
ENTRY(go_user)
        pushq $0xe02b
        pushq %rsp
        subq  $64,(%rsp)
        pushq $0x10212
        pushq $0xe030
        pushq $fail
        orb   $3,1*8(%rsp)
        orb   $3,4*8(%rsp)
        pushq $0
        jmp  hypercall_page + (__HYPERVISOR_iret * 32)

So I construct a stack frame that looks like an interrupt happened and
the next instruction to run is at 'fail'. I set the ring to ring3
(orb) and then do an iret.

The code switches the ESP and EIP and continued executing 'fail' in
user mode. I know for sure it is user mode because first it gave an
error that there is no user page table set (see below). Anyway, in
user mode the 'syscall' then works.

>> > BTW: I found building Xen with 'debug=y' generates a helpful comment on
>> > the console every now and xen.
>> 
>> I did that and added a patch that makes HYPERVISOR_console_io work for
>> domU so it shows up in "xm dmesg".
>
> Ah, I see. Good idea.
>
>> >> But still, the syscall opcode does nothing.
>> >> In case you wonder. The "int $80" is there to crash the domain and
>> >> tell me it reached that point.
>
> Shouldn't that just get you a GPF? 

Which calls the do_general_protection, if installed, which dumps the
registers:
GPF rip: 00000000001031fc, error_code=282
RIP: e030:[<00000000001031fc>] 
RSP: e02b:0000000000121fc8  EFLAGS: 00010212
RAX: 0000000000000000 RBX: 0000000000119000 RCX: 00000000001031fc
RDX: 0000000000000100 RSI: 00000000deadbeef RDI: 00000000deadbeef
RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000000
R10: 00000000fffffff9 R11: 0000000000000212 R12: 00000000001033ea
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

Without handler (or in other instances) the domain truely crashes and
'xen dmesg' has a nice register and stack dump like:

(XEN) traps.c:212:d18 Guest switching to user mode with no user page tables
(XEN) traps.c:241:d18 Fatal error
(XEN) Domain 18 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.0.4-1  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[<00000000001022eb>]
(XEN) RFLAGS: 0000000000000206   CONTEXT: guest
(XEN) rax: 0000000000000017   rbx: 0000000000119000   rcx: 00000000001022eb
(XEN) rdx: 0000000000000100   rsi: 00000000deadbeef   rdi: 00000000deadbeef
(XEN) rbp: 0000000000000000   rsp: 0000000000108d00   r8:  00000000ffffffff
(XEN) r9:  0000000000000000   r10: 00000000fffffffc   r11: 0000000000000206
(XEN) r12: 00000000001033ea   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) cr3: 000000005b50f000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=0000000000108d00:
(XEN)    0000000000000000 0000000000000001 000000000011b000 0000000000000000
(XEN)    00000000001033ea 000000000000e033 0000000000010212 0000000000108d00
(XEN)    000000000000e02b 0000000000105872 0000000000000000 0000000000000000
...

Both I find rather helpfull in debugging. :)

> regards,
> Daniel

MfG
        Goswin

Re: Using SYSCALL/SYSRET with a minios kernel

[Daniel Stodden]

On Mon, 2008-02-25 at 14:14 +0100, Goswin von Brederlow wrote:
> Daniel Stodden <stodden@cs.tum.edu> writes:
> 
> > On Mon, 2008-02-25 at 11:04 +0100, Goswin von Brederlow wrote:
> >
> >> >> --- kernel.c ---
> >> >>   HYPERVISOR_set_callbacks((unsigned long)hypervisor_callback,
> >> >> 			   (unsigned long)failsafe_callback,
> >> >> 			   (unsigned long)syscall_callback);
> >> >> 
> >> >>   __asm__ __volatile__("syscall");
> >> >> 
> >> >> If I understood you right that should set the RIP to syscall_callback
> >> >> and execute from there.
> >> >
> >> > Mööp! Only when calling in from virtual user mode. Otherwise, you're
> >> > triggering a hypercall service routine, and one might suspect you're
> >> > presently just generating an error condition with that. :)
> >> 
> >> That sounds verry odd. I'm getting no indication of it from xen.
> >
> > Why odd? That's how e.g. syscall processing in Xen's entry.S is structured.
> > Many hypercalls fail with messages. But e.g. an invalid hypercall number
> > would silently return -ENOSYS, so it does not appear too unlikely. 
> > What do you get instead?
> 
> Nothing. The 'syscall' instruction behaves like a 'nop'. If Xen's
> syscall emulation fails then I would expect it to raise some
> exception, e.g. illegal instruction.
> 
> The amd64 tech docs indicate that syscall can be used recursively
> (indicated by SS == 0) and no check on the CPL is performed by
> 'syscall'. So I would expect that i could call 'syscall' even in
> kernel mode in Xen too. But now that I know better that is ok too.

Well, that's how x86 does it. But the PV interface is only meant to
reflect x86 to a degree which provide fur i) porting existing OSs sane
and simple ii) keeps the hypervisor small and lean. Both at the same
time. And to my limited knowledge, syscalls from kernel mode are not
exactly a killer feature in practical x86 os design.

> >> But ok. How do I test that. Or differently phrased: What is the best
> >> way to go into user space for the verry first time? Do I really have
> >> to create a fake stack frame and call HYPERVISOR_iret?
> >
> > iret is the only method I am aware of, can't think about anything else. Doubt
> > that a stack switch would be forcibly required.
> >
> > Does not neccesarily mean much, however, since I did not write the freaky thing.
> 
> I added the following code to x86_64.S:
> 
> ENTRY(fail)
>         syscall
>         int $3
>         jmp fail
>         
> ENTRY(go_user)
>         pushq $0xe02b
>         pushq %rsp
>         subq  $64,(%rsp)
>         pushq $0x10212
>         pushq $0xe030
>         pushq $fail
>         orb   $3,1*8(%rsp)
>         orb   $3,4*8(%rsp)
>         pushq $0
>         jmp  hypercall_page + (__HYPERVISOR_iret * 32)
> 
> So I construct a stack frame that looks like an interrupt happened and
> the next instruction to run is at 'fail'. I set the ring to ring3
> (orb) and then do an iret.
> 
> The code switches the ESP and EIP and continued executing 'fail' in
> user mode. I know for sure it is user mode because first it gave an
> error that there is no user page table set (see below). Anyway, in
> user mode the 'syscall' then works.

Good.

> >> > BTW: I found building Xen with 'debug=y' generates a helpful comment on
> >> > the console every now and xen.
> >> 
> >> I did that and added a patch that makes HYPERVISOR_console_io work for
> >> domU so it shows up in "xm dmesg".
> >
> > Ah, I see. Good idea.
> >
> >> >> But still, the syscall opcode does nothing.
> >> >> In case you wonder. The "int $80" is there to crash the domain and
> >> >> tell me it reached that point.
> >
> > Shouldn't that just get you a GPF? 
> 
> Which calls the do_general_protection, if installed, which dumps the
> registers:
> GPF rip: 00000000001031fc, error_code=282
> RIP: e030:[<00000000001031fc>] 
> RSP: e02b:0000000000121fc8  EFLAGS: 00010212
> RAX: 0000000000000000 RBX: 0000000000119000 RCX: 00000000001031fc
> RDX: 0000000000000100 RSI: 00000000deadbeef RDI: 00000000deadbeef
> RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000000
> R10: 00000000fffffff9 R11: 0000000000000212 R12: 00000000001033ea
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> 
> Without handler (or in other instances) the domain truely crashes and
> 'xen dmesg' has a nice register and stack dump like:
> 
> (XEN) traps.c:212:d18 Guest switching to user mode with no user page tables
> (XEN) traps.c:241:d18 Fatal error
> (XEN) Domain 18 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-3.0.4-1  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e033:[<00000000001022eb>]
> (XEN) RFLAGS: 0000000000000206   CONTEXT: guest
> (XEN) rax: 0000000000000017   rbx: 0000000000119000   rcx: 00000000001022eb
> (XEN) rdx: 0000000000000100   rsi: 00000000deadbeef   rdi: 00000000deadbeef
> (XEN) rbp: 0000000000000000   rsp: 0000000000108d00   r8:  00000000ffffffff
> (XEN) r9:  0000000000000000   r10: 00000000fffffffc   r11: 0000000000000206
> (XEN) r12: 00000000001033ea   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
> (XEN) cr3: 000000005b50f000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=0000000000108d00:
> (XEN)    0000000000000000 0000000000000001 000000000011b000 0000000000000000
> (XEN)    00000000001033ea 000000000000e033 0000000000010212 0000000000108d00
> (XEN)    000000000000e02b 0000000000105872 0000000000000000 0000000000000000
> ...
> 
> Both I find rather helpfull in debugging. :)

Ah, I see.

regards,
daniel

-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B