[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 1/2] xen: introduce arch_iommu_grant_(un)map_page
On 24/07/14 12:16, Stefano Stabellini wrote:
On Thu, 24 Jul 2014, Julien Grall wrote:
On 24/07/14 12:07, Stefano Stabellini wrote:
On Thu, 24 Jul 2014, Julien Grall wrote:
Hi Stefano,
The Title of the commit message is now wrong.
Thanks, I didn't notice.
On 23/07/14 18:19, Stefano Stabellini wrote:
Introduce two arch specific functions to create a new p2m mapping of
granted pages at pfn == mfn.
The x86 implementation just returns ENOSYS.
Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
---
xen/arch/arm/p2m.c | 19 +++++++++++++++++++
xen/include/asm-arm/p2m.h | 4 ++++
xen/include/asm-x86/p2m.h | 13 +++++++++++++
3 files changed, 36 insertions(+)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 9960e17..c38af59 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -555,6 +555,25 @@ void guest_physmap_remove_page(struct domain *d,
pfn_to_paddr(mfn), MATTR_MEM, p2m_invalid);
}
+int arch_grant_map_page_identity(struct domain *d, unsigned long frame,
+ bool_t writeable)
+{
+ p2m_type_t t;
+
+ if ( writeable )
+ t = p2m_ram_rw;
+ else
+ t = p2m_ram_ro;
This is not the right p2m type to use here. p2m_ram_{rw,ro} allow foreign
mapping. So another guest could access to the grant.
I would use p2m_iommu_map_{rw,ro}.
I see. I'll make the change and add a comment to explain why we are
using p2m_iommu types for non-iommu related mappings.
The code to add the 1:1 mapping for the SMMU is very ugly. I was wondering if
we could drop the iommu_map_page callback and
directly use arch_grant_map_page_identity in all the case.
It would avoid the if/else in the grant code.
Thing is arch_grant_map_page_identity has nothing to do with IOMMUs. It
gets confusing, especially on x86 where people don't know why we need
this. The if/else is ugly but clearer.
See also the previous email exchange with Jan.
Ok. So could we call this function from iommu_map_page on the SMMU? It
would at least avoid duplicating the code?
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|