From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [RFC 3/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode Date: Tue, 11 Aug 2015 10:55:35 +0100 Message-ID: <20150811095535.GA884@deinos.phlegethon.org> 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> <55C87989.6050700@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <55C87989.6050700@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel@lists.xensource.com, keir@xen.org, ian.campbell@citrix.com, george.dunlap@eu.citrix.com, jbeulich@suse.com, Ben Catterall List-Id: xen-devel@lists.xenproject.org At 11:14 +0100 on 10 Aug (1439205273), Andrew Cooper wrote: > 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. Right, and this is why we need a third stack - so interrupts don't trash the existing priv state on the 'normal' Xen stack. And so we either need to copy the priv stack out (and maybe copy it back), or tell the CPU to use a different stack. If we had enough headroom, we could try to be clever and tell the CPU to take interrupts on the priv stack _below_ the existing state. That would avoid the first of your problems below. > * 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) Gah, this thing. :( Tim.