Re: [Xen-devel] Using SYSCALL/SYSRET with a minios kernel

[Daniel Stodden <stodden@xxxxxxxxxx>]

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@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



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