Xen devel - Oct 2007 - Question regarding user-mode and debugging terminals

Dear xen-devel,

My partner and I are working to port an "educational"
UNIX-like operating system from a custom simulator to
the Xen platform for an operating systems class here
at Brown University.

Unfortunately, we''re having quite a bit of difficulty
switching the system into user mode. Currently, we''re
using borrowed code from an early linux kernel:

89 void context_make_active_user(context_t *c)
 90 {
 91     /* Switch stacks and run the thread */
 92     int res;
 93     res = switch_into_user_as(c);
 94   //move_to_user_mode();
 95   //#define move_to_user_mode()
 96 //  __asm__ __volatile__ ("movl %%esp,%%eax\n\t" \
 97     "pushl %0\n\t" \
 98     "pushl %%eax\n\t" \
 99     "pushfl\n\t" \
100     "pushl %1\n\t" \
101     "pushl $1f\n\t" \
102     "iret\n" \
103     "1:\tmovl %0,%%eax\n\t" \
104     "mov %%ax,%%ds\n\t" \
105     "mov %%ax,%%es\n\t" \
106     "mov %%ax,%%fs\n\t" \
107     "mov %%ax,%%gs" \
108     : /* no outputs */ :"i" (__USER_DS), "i"
(__USER_CS):"ax");
109     KASSERT(!res);
110     __asm__ __volatile__("movl %0,%%ebp\n\t"  /*
update ebp */
111                          "movl %1,%%esp\n\t"  /*
update esp */
112        "push %2\n\t"    /* save eip   */
113        "ret"      /* jump to new eip */
114              : : "m" (c->c_ebp), "m" (c->c_esp),
"m" (c->c_eip));
115 }

The code that has been commented out is our attempt to
alter the segment registers and switch to ring 3.
However, this seems to be very wrong. We are
struggling to find examples as to how this switch to
userland might be achieved while running with xen
(and, in fact, in general). Does anyone have any
advice that might help us implement this switch to
userland? Additionally, will returning from a trap
into the kernel from userland automatically switch
back to userland or is additional effort needed?
--
Second, students interacted with this OS (named
"Weenix") through three terminals which were exposed
to Weenix as character devices /dev/tty0 through
/dev/tty3. Additional, the actual terminal through
which the Weenix system had been started would serve
as a console for printing "meta" debugging output to
(this terminal would not be visible to Weenix itself).

We''ve made significant ground porting Weenix to Xen
(which we have renamed "Wox"), however, we''re a bit
hung up in trying to simulate those original three
terminals without going overboard.

We''ve toyed with the idea of simply using escape
sequence to "split" a single terminal, but this seems
ugly and is not truly what we''d like. We''d much prefer
a way to attach multiple terminals to a single Weenix
instance such that Weenix can interact with these
terminals as if they were character devices. 

One option seems to be modifying the "back-end" driver
utilized by block I/O devices but this seems as though
it would require us to alter Xen itself. Beyond this,
we''re really not sure how to proceed. Any pointers or
general advice would be greatly appreciated.
Unfortunately, Weenix doesn''t have a network stack;
it''s only three or four times more complex than
mini-os :)

Thank you very much!

Brandon & Dan
Brown University


       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433

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

> My partner and I are working to port an "educational"
> UNIX-like operating system from a custom simulator to
> the Xen platform for an operating systems class here
> at Brown University.
>
> Unfortunately, we''re having quite a bit of difficulty
> switching the system into user mode. Currently, we''re
> using borrowed code from an early linux kernel:
I''ll leave this query to someone more familiar with the low level
details!
> Second, students interacted with this OS (named
> "Weenix") through three terminals which were exposed
> to Weenix as character devices /dev/tty0 through
> /dev/tty3. Additional, the actual terminal through
> which the Weenix system had been started would serve
> as a console for printing "meta" debugging output to
> (this terminal would not be visible to Weenix itself).
>
> We''ve made significant ground porting Weenix to Xen
> (which we have renamed "Wox"), however, we''re a bit
> hung up in trying to simulate those original three
> terminals without going overboard.
>
> We''ve toyed with the idea of simply using escape
> sequence to "split" a single terminal, but this seems
> ugly and is not truly what we''d like. We''d much prefer
> a way to attach multiple terminals to a single Weenix
> instance such that Weenix can interact with these
> terminals as if they were character devices.
The correct approach here if you want to add "real" terminals would be
to
modify the Xen console framework to support them.  Off the top of my head 
you''d need to do something like:

1) modify the console backend and frontend drivers to understand the concept 
of multiple terminals (with appropriate backward compatibility so as not to 
break old frontends when they encounter a new backend - and preferably not 
break old backends if they encounter a new frontend).
2) modify Xend to configure multi-console operation so that the back and front 
ends know what they''re doing
3) modify console daemon to handle multiple consoles per guest and provide a 
means for user to connect
4) modify xm command syntax to handle connecting to multiple consoles per 
domain
5) invent a sensible config file format for it all
6) (optionally) make this play nicely with multiple virtual serial consoles 
for HVM guests - not required for your patch, and (I''d imagine) not
required
for patch inclusion either.

I''d say that none of this is really fundamentally difficult, there are
just
lots of things you''d need to hack on / tweak / fiddle with.  Lots of 
small-to-medium changes all over the tree.  But it is something that
we''ve
wanted for a while - it''s been on the roadmap as an
"Wouldn''t it be nice...?"
for ages.

This list would probably be able to give you some support if you wanted to do 
this, but obviously completing your own project has higher priority than 
improving ours ;-)  Still, if the two happen to coincide...

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

On 5/10/07 02:09, "The Evil Geek" <theevilgeek@yahoo.com> wrote:
> The code that has been commented out is our attempt to
> alter the segment registers and switch to ring 3.
> However, this seems to be very wrong. We are
> struggling to find examples as to how this switch to
> userland might be achieved while running with xen
> (and, in fact, in general). Does anyone have any
> advice that might help us implement this switch to
> userland? Additionally, will returning from a trap
> into the kernel from userland automatically switch
> back to userland or is additional effort needed?
Your problem does not look to be specific to running on Xen. Your approach
to switching to user space is a bit broken -- you cannot generally run
kernel code in ring 3, since the page-table protection for kernel mappings
is set to disallow ring-3 (user) accesses, since _PAGE_USER is clear in the
PTEs. So you are probably taking a page fault immediately after the iret
that is switching you to ring 3.

An approach that works is to set up a dummy trap frame so it looks like
user-space trapped to you. Then take your normal exit path from your OS.
This raises the question of what to set %esp and %eip to when initially
loading an application -- that is generally a question for your loader, and
will be discovered by looking at e.g., Elf metadata.

 -- Keir



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