From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [V3 PATCH 7/9] x86/hvm: pkeys, add pkeys support for guest_walk_tables Date: Fri, 18 Dec 2015 11:46:38 +0000 Message-ID: <20151218114638.GA48522@deinos.phlegethon.org> References: <1449479780-19146-1-git-send-email-huaitong.han@intel.com> <1449479780-19146-8-git-send-email-huaitong.han@intel.com> <5669C23F.6080203@citrix.com> <567184FF.9030702@citrix.com> <1450426913.4557.20.camel@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1450426913.4557.20.camel@intel.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: "Han, Huaitong" Cc: "Tian, Kevin" , "Wu, Feng" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , "george.dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , "Dong, Eddie" , "george.dunlap@citrix.com" , "xen-devel@lists.xen.org" , "jbeulich@suse.com" , "Nakajima, Jun" , "wei.liu2@citrix.com" , "keir@xen.org" , "ian.jackson@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org At 08:21 +0000 on 18 Dec (1450426907), Han, Huaitong wrote: > On Wed, 2015-12-16 at 15:36 +0000, George Dunlap wrote: > > With your current series, guest_walk_tables() already checks for > > pkeys > > being enabled in the guest before checking for them in the > > pagetables. > > For shadow mode, these will be false, and so no checks will be done. > > If > > anyone ever implements pkeys for shadow mode, then these will be > > enabled, and the checks will be done, without any intervention on the > > part of the caller. > > I have understood it, but, the problem with shadow mode is that pfec > may come from regs->error_code?hardware?, just like: > rc = sh_walk_guest_tables(v, va, &gw, regs->error_code); > so, when regs->error_code does not have PFEC_prot_key, > guest_walk_tables may still check PKEY when codes is writen according > to what you said, and it maybe return a different result. That's OK -- in general there's no guarantee that the guest walk will produce the same result as the original hardware fault, since the guest may have modified its pagetables. So flagging something as a pkey error when the original fault didn't is OK. OTOH, we shouldn't keep a hardware-supplied pkey bit in the PFEC unless the guest walk finds a reason for it to be there. IOW, we should treat it like the PFEC_present bit and have it depend only on the walk (or go straight to George's plan of separating inputs from outputs so that's not an issue). Cheers, Tim.