|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB
>>> On 19.03.18 at 17:57, <Paul.Durrant@xxxxxxxxxx> wrote: >> -----Original Message----- > [snip] >> >> How are you making sure this is a mapping that was established via >> >> the map op? Without that this can be (ab)used to ... >> >> >> >> > + put_page(page); >> >> >> >> ... underflow the refcount of a page. >> >> >> > >> > Yes, I guess I need to ensure that only non-RAM (i.e. RMRR and E820 >> reserved >> > areas) are mapped through the IOMMU or this could indeed be abused. >> >> Now I'm confused - then you don't need to deal with struct page_info >> and page references at all. Nor would you need to call >> get_page_from_gfn() and check p2m_is_any_ram(). Also - what use >> would the interface be if you couldn't map any RAM? >> > > Sorry to confuse... > > What I meant was that safety (against underflow) is predicated on > iommu_lookup_page() failing if the mapping was not established through an > iommu op hypercall. So, the only things that should be valid in the iommu > (and hence that iommu_lookup_page() would succeed for) at the point where the > guest starts to boot must all fall within reserved regions, so thay they are > ruled out by the earlier check. Ah, I see. What I don't see is how you want to arrange for that. The tool stack wouldn't know ahead of time whether the guest wants to use the PV IOMMU interfaces, would it? IOW rather than guaranteeing said state at start of guest, shouldn't you blow away all non-special mappings the first time a PV IOMMU request is made? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |