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

[Andrew Cooper <andrew.cooper3@citrix.com>]

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