From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= Subject: Re: Shared page tables between ETP and IOMMU issue Date: Thu, 26 Feb 2015 20:31:33 +0100 Message-ID: <54EF7495.4050000@citrix.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="windows-1252" 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 1YR4CS-0007TM-Ta for xen-devel@lists.xenproject.org; Thu, 26 Feb 2015 19:34:21 +0000 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: Jan Beulich Cc: yang.z.zhang@intel.com, xen-devel , kevin.tian@intel.com List-Id: xen-devel@lists.xenproject.org El 26/02/15 a les 19.02, Roger Pau Monn=E9 ha escrit: > 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 the >>> 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. BTW, if I set no-sharept the output is as expected: (XEN) print_vtd_entries: iommu ffff8302197c3a40 dev 0000:00:1f.2 gmfn 43e0 (XEN) root_entry =3D ffff8302197c0000 (XEN) root_entry[0] =3D 19793f001 (XEN) context =3D ffff83019793f000 (XEN) context[fa] =3D 2_140149001 (XEN) l4 =3D ffff830140149000 (XEN) l4_index =3D 0 (XEN) l4[0] =3D 140148003 (XEN) l3 =3D ffff830140148000 (XEN) l3_index =3D 0 (XEN) l3[0] =3D 140147003 (XEN) l2 =3D ffff830140147000 (XEN) l2_index =3D 21 (XEN) l2[21] =3D 14012c003 (XEN) l1 =3D ffff83014012c000 (XEN) l1_index =3D 1e0 (XEN) l1[1e0] =3D 1401e3003 (XEN) GFN: 0x43e0 MFN: 0x1401e3 type: 0