From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Catterall Subject: Re: [RFC 3/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode Date: Thu, 20 Aug 2015 15:42:04 +0100 Message-ID: <55D5E73C.3030002@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> <55C87989.6050700@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: 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 , Tim Deegan 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 11:14, 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. 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. From what I understand from entry.S's assembly: handle_ist_exception is used for machine_check and nmi ISTs and these perform this copy. The double fault handler does not do this copy. - we take the IST on a different stack page - the handler copies the guest's registers from its current page to the bottom of the privileged stack so access routines for this still work as usual - Moves its rsp to just after this structure in the privileged stack - Calls do_nmi - does a ret_from_intr with the stack ptr on the privileged stack Now, I _think_ it's sufficient to perform this copy and then just keep the rsp on the IST stack page (rather than moving it across as is currently done) so that we don't clobber the privileged stack. Then, on the return path, move our rsp back to the privileged stack, just after the guest registers so that ret_from_intr can use the copied (and possibly modified) guest's registers. Does that sound reasonable? Thanks in advance! > * AMD Task Register on vmexit. (this old gem) > > ~Andrew >