[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

 


Rackspace

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