Re: [Xen-devel] [RFC 3/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 17/08/15 08:07, Tim Deegan wrote:
> At 14:53 +0100 on 17 Aug (1439823232), Ben Catterall wrote:
> > On 12/08/15 14:33, Andrew Cooper wrote:
> > > On 12/08/15 14:29, Andrew Cooper wrote:
> > > > On 11/08/15 19:29, Boris Ostrovsky wrote:
> > > > > Would switching TR only when we know that we need to enter this
> > > > > deprivileged mode help?
> > > > This is an absolute must.  It is not safe to use syscall/sysexit without
> > > > IST in place for NMIs and MCEs.
> > > >
> > > > > Assuming that it is less expensive than copying the stack.
> > > > I was referring to the stack overflow issue, and whether it might be
> > > > sensible to pro-actively which TR.
> > > Ahem! s/which/switch/
> > >
> > > ~Andrew
> > So, have we arrived at a decision for this? Thanks!
Apologies for the delay - I am currently at the Xen Developer Summit.

> Seems to have stalled a bit.  OK, I propose that:
>   - we use TR/IST to make Xen take interrupts/exceptions at a different SP;
Xen re-enables interrupts in most interrupt handlers, which means that 
they must not have an IST set.  If an IST was set, a second interrupt 
would clobber the frame of the first.
However, just adjusting tss->rsp0 and syscall top-of-stack to the 
current rsp when entering depriv mode should be sufficient, and will 
avoid needing to copy the stack.
>   - we make that SP be an extension of the main stack, so that things
>     like current() Just Work[tm];
>   - we set this up and tear it down when we enter/leave depriv mode.
>   - someone ought to look at the case where IST handlers copy
>     themselves to the main stack, and see if we need to adjust that too.
They will need adjusting, but just disabling the copy entirely should be ok.

> Any other proposals?
>
> I think we can leave the question of TR switching on VMEXIT as a
> separate issue.
Agreed.  It is orthogonal to this problem.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel