Re: [Xen-devel] [RFC PATCH resend] PVH Dom0 RMRR IOMMU mapping regression fix

[Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>]

On Fri, Sep 25, 2015 at 12:36:09AM -0600, Jan Beulich wrote:
> >>> On 25.09.15 at 01:53, <elena.ufimtseva@xxxxxxxxxx> wrote:
> > Permissions for p2m entry of read-only 
> > mmio regions are left unchanged as leaving only 'r' cause page faults. I am 
> > not sure what the reason of it yet, will try to dig it further.
> 
> Yes please - imo this absolutely should be changed to just r along
> with the rwx -> rw conversion. Since you saw page faults, could
> you at least point out which address(es) they occurred for? After
> all the set of r/o MMIO pages should be relatively small...

I did verify it with clean build and I cannot reproduce it anymore.
But that is the Page Fault I saw:

XEN) [VT-D]iommu.c:873: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:875: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:1f.2] fault addr
1b56000, iommu reg = ffff82c000203000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
(XEN) print_vtd_entries: iommu ffff830412a4b9c0 dev 0000:00:1f.2 gmfn
1b56
(XEN)     root_entry = ffff830412a48000
(XEN)     root_entry[0] = 291cbd001
(XEN)     context = ffff830291cbd000
(XEN)     context[fa] = 2_2920c7001
(XEN)     l4 = ffff8302920c7000
(XEN)     l4_index = 0
(XEN)     l4[0] = 2920c6003
(XEN)     l3 = ffff8302920c6000
(XEN)     l3_index = 0
(XEN)     l3[0] = 2920c5003
(XEN)     l2 = ffff8302920c5000
(XEN)     l2_index = d
(XEN)     l2[d] = 2920b5003
(XEN)     l1 = ffff8302920b5000
(XEN)     l1_index = 156
(XEN)     l1[156] = 0
(XEN)     l1[156] not present

Device is not reported in DMAR, the gfn mapped with p2m_ram_rw type...

lspci:

00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 
6-port SATA Controller 1 [AHCI mode] (rev 05) (prog-if 01 [AHCI 1.0])
    Subsystem: Lenovo Device 3097
    Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 84
    I/O ports at f0d0 [size=8]
    I/O ports at f0c0 [size=4]
    I/O ports at f0b0 [size=8]
    I/O ports at f0a0 [size=4]
    I/O ports at f060 [size=32]
    Memory at f7c36000 (32-bit, non-prefetchable) [size=2K]
    Capabilities: <access denied>
    Kernel driver in use: ahci


But as I say, I cannot reproduce it, will run few more tests.

> 
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -971,7 +971,17 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
> > long gfn,
> >          ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> >                              p2m_mmio_direct, p2ma);
> >      else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
> > -        ret = 0;
> > +    {
> > +        /*
> > +         * PVH fixme: during Dom0 PVH construction, p2m entries are being 
> > set
> > +         * but iomem regions are not mapped with IOMMU. This makes sure 
> > that
> > +         * RMRRs are correctly mapped with IOMMU.
> > +         */
> > +        if ( is_hardware_domain(d) && !iommu_use_hap_pt(d) )
> > +            ret = iommu_map_page(d, gfn, gfn, 
> > IOMMUF_readable|IOMMUF_writable);
> 
> This should use p2m_get_iommu_flags() (which eventually needs to
> also honor the passed in p2m_access_t, i.e. its use here for now
> only serves documentation purposes as well as a means to spot the
> location when making said adjustment).

Here is the problem: for p2m_mmio_direct type p2m_get_iommu_flags() will
return 0. And that is essentially why 1:1 iomem mapping for Dom0 PVH
does set p2m entries, but does not create identity mapping in
construct_dom0.

Do you mean when saying 'honoring p2m_access_t' that p2m_get_iommu_flags should
be more like ept_p2m_type_to_flags() where permissions are verified?
Right now even if rw permissions are requested, the type p2m_mmio_direct will 
always
return IOMMU flags being zero from p2m_get_iommu_flags();

> 
> Jan
> 

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