From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [RFC 3/4] HVM x86 deprivileged mode: Code for
 switching into/out of deprivileged mode
Date: Mon, 10 Aug 2015 11:14:33 +0100
Message-ID: <55C87989.6050700@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"
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>, Ben Catterall <Ben.Catterall@citrix.com>
Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org, ian.campbell@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?

That should happen naturally by virtue of the privilege level change
involved in taking the interrupt.  Conceptually, taking interrupts from
depriv mode is no different to taking them in a PV guest.

Some complications which come to mind (none insurmountable):

* Under this model, PV exception handlers should copy themselves onto
the privileged execution stack.
* Currently, the IST handlers  copy themselves onto the primary stack if
they interrupt guest context.
* AMD Task Register on vmexit.  (this old gem)

~Andrew