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

[Ben Catterall <Ben.Catterall@citrix.com>]

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