From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Catterall <Ben.Catterall@citrix.com>
Subject: Re: [RFC 3/4] HVM x86 deprivileged mode: Code for
 switching into/out of deprivileged mode
Date: Tue, 11 Aug 2015 11:35:11 +0100
Message-ID: <55C9CFDF.2010303@citrix.com>
References: <1438879519-564-1-git-send-email-Ben.Catterall@citrix.com>
	<1438879519-564-4-git-send-email-Ben.Catterall@citrix.com>
	<20150810094928.GC3094@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20150810094928.GC3094@deinos.phlegethon.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com, keir@xen.org, ian.campbell@citrix.com, george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com, jbeulich@suse.com
List-Id: xen-devel@lists.xenproject.org



On 10/08/15 10:49, Tim Deegan wrote:
> Hi,
>
> At 17:45 +0100 on 06 Aug (1438883118), Ben Catterall wrote:
>> The process to switch into and out of deprivileged mode can be likened to
>> setjmp/longjmp.
>>
>> To enter deprivileged mode, we take a copy of the stack from the guest's
>> registers up to the current stack pointer.
>
> This copy is pretty unfortunate, but I can see that avoiding it will
> be a bit complex.  Could we do something with more stacks?  AFAICS
> there have to be three stacks anyway:
>
>   - one to hold the depriv execution context;
>   - one to hold the privileged execution context; and
>   - one to take interrupts on.
>
> So maybe we could do some fiddling to make Xen take interrupts on a
> different stack while we're depriv'd?
>
> If we do have to copy, we could track whether the original stack has
> been clobbered by an interrupt, and so avoid (at least some of) the
> copy back afterwards?
>
> One nit in the assembler - if I've followed correctly, this saved IP:
>
>> +        /* Perform a near call to push rip onto the stack */
>> +        call   1f
>
> is returned to (with adjustments) here:
>
>> +        /* Go to user mode return code */
>> +        jmp    *(%rsi)
>
> It would be good to make this a matched pair of call/ret if we can;
> the CPU has special branch prediction tracking for function calls that
> gets confused by a call that's not returned to.
>
sure, will do.
> Cheers,
>
> Tim.
>