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

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





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


 


Rackspace

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