[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] progress and a problem



> So, it seems Xen has descheduled my Plan 9 guest but only the CS/IP is on 
> the stack. Is there any way at all this could happen? it's very puzzling.
> When Xen deschedules a domain does it force an interrupt or ...

Which stack are you talking about here? When Xen first deschedules
your while(1), the CPU should write CS,EIP,EFLAGS,SS,ESP onto Xen's
ring-0 stack.

When you get a callback, Xen should see that it is 'interrupting' an
existing ring-1 activation, and read the appropriate SS,ESP from its
own (ring-0) stack. When it writes the activation frame for teh
callback, it will only write CS,EIP,EFLAGS. SS,ESP will not be written
to your ring-1 stack because the IRET at the end of your callback
handler will not be changing privilege levels.

The same goes for your page fault: Xen will use the SS,ESP saved on it
own stack, and will not write a SS,ESP pair onto your stack.

> Also, I should mention: I have not done an LIDT or LTR because I was 
> hoping to just use the Xen default one for the domain (as I do for the 
> GDT). How much trouble could this cause? It seems to have been working 
> fine for a few weeks, so I assumed it was no harm done.

Task segments aren't virtualised, so there is no equivalent of
LTR. The quivalent of LIDT is set_trap_table() which you must have
called to be taking page faults.

 -- Keir


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.