Re: [Xen-devel] Shared page tables between ETP and IOMMU issue

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.02.15 at 19:02, <roger.pau@xxxxxxxxxx> wrote:
> 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.

So obviously we'd want to see the EPT page table walk for the
same GFN for comparison. I'd expect them to differ at some
higher level already, and be wrong possibly because of the
context[] slot not having got updated at some point after its
initial setup (or the other way around - the context slot having
got updated without consideration of EPT, albeit that seems
less likely).

And then of course the question arises why you see this issue
with FreeBSD, but no-one so far saw it with Linux. Did you try
PVH Linux on that particular box (i.e. to tell a machine specific
issue from a guest dependent one)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel