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

[Ben Catterall <Ben.Catterall@xxxxxxxxxx>]

On 18/08/15 17:55, Andrew Cooper wrote:
> 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.
No worries! Hope you're enjoying the 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.
Got it, thanks!
> >   - 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.
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