From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode Date: Mon, 17 Aug 2015 15:58:50 +0100 Message-ID: <20150817145850.GA42311@deinos.phlegethon.org> References: <1438879519-564-1-git-send-email-Ben.Catterall@citrix.com> <1438879519-564-5-git-send-email-Ben.Catterall@citrix.com> <20150810100755.GD3094@deinos.phlegethon.org> <55C9CF7D.5070500@citrix.com> <55D1E8AE.1080005@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: <55D1E8AE.1080005@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: Ben Catterall 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 At 14:59 +0100 on 17 Aug (1439823550), Ben Catterall wrote: > On 11/08/15 11:33, Ben Catterall wrote: > > On 10/08/15 11:07, Tim Deegan wrote: > >> This should happen in paging_fault() so it can guard the > >> shadow-pagetable paths too. Once it's there, it'll need a check for > >> is_hvm_vcpu() as well as for user_mode. Maybe have a helper function > >> 'is_hvm_deprivileged_vcpu()' to do both checks, also used in > >> hvm_deprivileged_check_trap() &c. > I've moved this and now need to add shadow page table support as this > currently only supports HAP. Thanks. There shouldn't be very much work to do for this -- after all we're not running in the guest's pagetables so the actual shadow PT mechanism won't be needed. Maybe just a common helper function called from the shadow & hap monitor-table builders? > >> I wonder whether it would be better to switch to an IDT with all > >> unacceptable traps stubbed out, rather than have to blacklist them all > >> separately. Probably not - this check is cheap, and maintaining the > >> parallel tables would be a pain. > >> > >> Or maybe there's some single point upstream of here, in the asm > >> handlers, that would catch all the cases where this check is needed? > >> > > Yep, I think this can be done. > Had a deeper look at this. There is a point where all exceptions come in > in the asm (handle_exception in entry.S) and we could branch out at this > point. It does mean that we'd treat _all_ exceptions that occur in this > mode the same way whereas the current way means that we can treat them > differently (e.g. get __func__). So, should I make all exceptions go to > the same point or keep as is? I think trap them all at the same point, unless you plan to have any exceptions that don't just kill the guest. I don't think you do, do you? This code is really Jan and Andrew's area, though. Cheers, Tim.