[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Shared page tables between ETP and IOMMU issue
El 26/02/15 a les 17.43, Jan Beulich ha escrit: >>>> On 26.02.15 at 17:29, <roger.pau@xxxxxxxxxx> 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 = ffff8302197c0000 (XEN) root_entry[0] = 140144001 (XEN) context = ffff830140144000 (XEN) context[fa] = 2_140148001 (XEN) l4 = ffff830140148000 (XEN) l4_index = 0 (XEN) l4[0] = 140147003 (XEN) l3 = ffff830140147000 (XEN) l3_index = 0 (XEN) l3[0] = 140146003 (XEN) l2 = ffff830140146000 (XEN) l2_index = 21 (XEN) l2[21] = 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. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |