From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [V1 PATCH] PVH: avoid call to handle_mmio Date: Fri, 6 Jun 2014 12:42:13 -0700 Message-ID: <20140606124213.4dd4716b@mantra.us.oracle.com> References: <1401832802-27118-1-git-send-email-mukesh.rathor@oracle.com> <1401832802-27118-2-git-send-email-mukesh.rathor@oracle.com> <538EE5BF02000078000179E7@mail.emea.novell.com> <20140604165221.1ccaa596@mantra.us.oracle.com> <53902A2E02000078000180D9@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wt01t-0005zp-2f for xen-devel@lists.xenproject.org; Fri, 06 Jun 2014 19:42:21 +0000 In-Reply-To: <53902A2E02000078000180D9@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@lists.xenproject.org, keir.xen@gmail.com List-Id: xen-devel@lists.xenproject.org On Thu, 05 Jun 2014 07:28:30 +0100 "Jan Beulich" wrote: > >>> On 05.06.14 at 01:52, wrote: > > On Wed, 04 Jun 2014 08:24:15 +0100 > > "Jan Beulich" wrote: > > > >> >>> On 04.06.14 at 00:00, wrote: > >> > handle_mmio() is currently unsafe for pvh guests. A call to it > >> > would result in call to vioapic_range that will crash xen since > >> > the vioapic ptr in struct hvm_domain is not initialized for pvh > >> > guests. > >> > > >> > However, one path exists for such a call. If a pvh guest, dom0 or > >> > domU, unintentionally touches non-existing memory, an EPT > >> > violation would occur. This would result in unconditional call to > >> > hvm_hap_nested_page_fault. In that function, because > >> > get_gfn_type_access returns p2m_mmio_dm for non existing mfns by > >> > default, handle_mmio() will get called. This would result in xen > >> > crash instead of the guest crash. This patch addresses that. > >> > >> Yes, we definitely want this until being properly handled, no > >> matter that crashing the guest here doesn't seem to be the right > >> thing either (normal x86 behavior would be to drop writes and > >> return all ones for reads). > > > > How about doing the same we do for HVM which is inject GP. Then > > handle_mmio would just return 0 for pvh, and > > hvm_hap_nested_page_fault would not need to be modified. > > The fundamentally wrong thing is that real hardware wouldn't > surface #GP on any wrong physical address - with one exception, > the only possibility would be #MC, and I don't think this would > ever happen for truly unpopulated ranges. (The exception being > on AMD, where #PF gets surfaced when trying to access a page > referring to the HT reserved address range.) IOW even on HVM > it is wrong for us to inject #GP in cases like this. We, internally here, discussed the idea of injecting #PF instead of #GP. That makes sense from baremetal perspective. IOW, if we look at it from the prespective that the guest kernel put a bad pte entry, then on baremetal it will get a #PF. Moreover, a PV guest returns 0 for mfn if the p2m lookup fails, and in some paths it appears the code does do_mmu_update subsequently.... which should result in guest getting a NULL ptr later. -Mukesh