[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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.