From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH] x86/HVM: extend LAPIC shortcuts around P2M lookups Date: Wed, 6 Aug 2014 11:38:05 +0200 Message-ID: <20140806093805.GC1305@deinos.phlegethon.org> References: <53DBB5860200007800028738@mail.emea.novell.com> <53DBBFF302000078000287BE@mail.emea.novell.com> <20140801191530.GB95600@deinos.phlegethon.org> <53DF4E710200007800028CBE@mail.emea.novell.com> <20140805195351.GB49794@deinos.phlegethon.org> <53E2049A0200007800029AED@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XExfh-000252-Ly for xen-devel@lists.xenproject.org; Wed, 06 Aug 2014 09:38:13 +0000 Content-Disposition: inline In-Reply-To: <53E2049A0200007800029AED@mail.emea.novell.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: Jan Beulich Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org At 09:34 +0100 on 06 Aug (1407314042), Jan Beulich wrote: > >>> On 05.08.14 at 21:53, wrote: > > At 08:12 +0100 on 04 Aug (1407136337), Jan Beulich wrote: > >> >>> On 01.08.14 at 21:15, wrote: > >> > If Xen does its own instruction fetch and decode, then we have to be > >> > careful about reusing any state from the original exit because of > >> > self-modifying code. (And yes, that is a serious concern -- I once > >> > spent months trying to debug occasional memory corruption in the > >> > self-modifying license-enforcement code on a system stress test > >> > utility.) > >> > > >> > So it would be OK to reuse the GPA from the exit if we could verify > >> > that the GVA we see is the same as the original fault (since there can't > >> > have been a TLB flush). But IIRC the exit doesn't tell us the > >> > original GVA. :( > >> > >> I don't think it needs to be as strict as this: For one, I wouldn't > >> intend to use the known GPA for instruction fetches at all. And > >> then I think if the instruction got modified between the exit and us > >> doing the emulation, using the known GPA with the wrong > >> instruction is as good or as bad as emulating an instruction that > >> didn't originally cause the exit. > > > > Not at all -- as I said, in the shadow code we did see the case where > > we emulated a different instruction, and we do our best to handle it. > > And at least there we have a clean failure mode: if we can't emulate > > we crash. > > > > Using the wrong GPA will silently corrupt memory and carry on, which > > is about the worst failure mode a VMM can have (esp. if skipping the > > GVA->GPA walk could allow a guest process to write to a read-only > > mapping). > > Indeed, thinking about it again I agree. Fortunately it looks like we're > having ways to accelerate this nevertheless: On EPT, the handler > gets the linear address, we just need to make use of it. I just finished > drafting a respective patch - hopefully I'll get to trying it out later > today. > > > I'd be extremely uncomfortable with anything like tis unless there's a > > way to get either the ifetch buffer or a partial decode out of the CPU > > (which IIRC can't be done on x86 though it can on ARM). > > On NPT we also get the instruction bytes on nested page faults, at > least on newer hardware. So maybe we could cook up something > along the lines you indicate by flagging that the instruction bytes > came from hardware. Oh good -- yes, both of those approaches sound very encouraging. Tim.