From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Shared page tables between ETP and IOMMU issue Date: Thu, 26 Feb 2015 14:28:30 -0500 Message-ID: <20150226192829.GA30038@x230.dumpdata.com> References: <54EF3F8A.5020608@citrix.com> <54EF507902000078000642F7@mail.emea.novell.com> <54EF49F0.3080000@citrix.com> <54EF5B2E02000078000643EA@mail.emea.novell.com> <54EF5FAE.2040706@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YR472-0005Vg-NK for xen-devel@lists.xenproject.org; Thu, 26 Feb 2015 19:28:44 +0000 Content-Disposition: inline In-Reply-To: <54EF5FAE.2040706@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: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: yang.z.zhang@intel.com, xen-devel , kevin.tian@intel.com, ufimtseva@gmail.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org On Thu, Feb 26, 2015 at 07:02:22PM +0100, Roger Pau Monn=E9 wrote: > El 26/02/15 a les 17.43, Jan Beulich ha escrit: > >>>> On 26.02.15 at 17:29, wrote: > >> OK, I will try to take a look. All those faults come from physical > >> memory ranges that are supposed to be usable, and in fact the CPU seems > >> to be able to read/write from them without problems, or else the guest > >> would have crashed much more early. Regarding sharing the page tables > >> between EPT and the IOMMU, is there some bit that needs to be set in t= he > >> ept entry in order to mark a page as available by the IOMMU? > > = > > Bits 0 and 1 (read and write) are shared between VT-d and EPT > > (as is bit 7 - see struct dma_pte and ept_entry_t). > = > I've added some debug prints at the end of construct_dom0 to print the = > MFN of a RAM page (using get_gfn_query_unlocked) and the VTd entry = > (using print_vtd_entries): > = > (XEN) print_vtd_entries: iommu ffff8302197c3a40 dev 0000:00:1f.2 gmfn 43e0 > (XEN) root_entry =3D ffff8302197c0000 > (XEN) root_entry[0] =3D 140144001 > (XEN) context =3D ffff830140144000 > (XEN) context[fa] =3D 2_140148001 > (XEN) l4 =3D ffff830140148000 > (XEN) l4_index =3D 0 > (XEN) l4[0] =3D 140147003 > (XEN) l3 =3D ffff830140147000 > (XEN) l3_index =3D 0 > (XEN) l3[0] =3D 140146003 > (XEN) l2 =3D ffff830140146000 > (XEN) l2_index =3D 21 > (XEN) l2[21] =3D 0 > (XEN) l2[21] not present > (XEN) GFN: 0x43e0 MFN: 0x1401e3 type: 0 > = > This is before Dom0 has been started, so I think there's something = > wrong in the way we build the page tables, because AFAICT the VTd = > code is not able to resolve the GFN, but the EPT code is. This looks like what Elena was hitting (how we parsed E820_RSV or MMIO ranges). Are those GPFNs special? = > = > Roger. > = > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel