Re: Shared page tables between ETP and IOMMU issue

["Roger Pau Monné" <roger.pau@citrix.com>]

El 26/02/15 a les 20.28, Konrad Rzeszutek Wilk ha escrit:
> On Thu, Feb 26, 2015 at 07:02:22PM +0100, Roger Pau Monné wrote:
>> El 26/02/15 a les 17.43, Jan Beulich ha escrit:
>>>>>> On 26.02.15 at 17:29, <roger.pau@citrix.com> 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.
> 
> This looks like what Elena was hitting (how we parsed E820_RSV or
> MMIO ranges). Are those GPFNs  special? 

No, they are regular RAM (p2m_ram_rw). I think Elena's problem was due
to missing RMRR regions in the ACPI tables. On the other hand this is
the IOMMU failing to provide translations for RAM regions. It seems like
it's caused by sharing the page tables between EPT and the IOMMUs.

Roger.