[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3.1 08/15] x86/vtd: fix mapping of RMRR regions
>>> On 04.11.16 at 13:25, <roger.pau@xxxxxxxxxx> wrote: > On Fri, Nov 04, 2016 at 04:34:58AM -0600, Jan Beulich wrote: >> >>> On 04.11.16 at 10:45, <roger.pau@xxxxxxxxxx> wrote: >> > case p2m_invalid: >> > case p2m_mmio_dm: >> > ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K, >> > p2m_mmio_direct, p2ma); >> > if ( ret ) >> > break; >> > if ( !iommu_use_hap_pt(d) ) >> > ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable); >> > break; >> > case p2m_mmio_direct: >> > if ( a != p2ma || gfn != mfn ) >> > { >> > printk(XENLOG_G_WARNING >> > "Cannot setup identity map d%d:%lx, already mapped with " >> > "different access type or mfn\n", d->domain_id, gfn); >> > ret = (flag & XEN_DOMCTL_DEV_RDM_RELAXED) ? 0 : -EBUSY; >> > break; >> > } >> > if ( !iommu_use_hap_pt(d) ) >> > ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable); >> >> Well, since according to what I've said above this code should >> really not be here, I think the code structuring question is moot >> now. The conditional call to iommu_map_page() really just needs >> adding alongside the p2m_set_entry() call. > > OK, so if the gfn is already mapped into the p2m we don't care whether it > has a valid IOMMU mapping or not? We do care, but it is the responsibility of whoever established the first mapping to make sure it's present in both P2M and IOMMU. IOW if the GFN is already mapped, we should be able to imply that it's mapped in both places. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |