|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 4/4] xen/arm: grant: Add another entry to map MFN 1:1 in dom0 p2m
On Mon, 2014-05-19 at 17:24 +0100, Julien Grall wrote:
> Grant mapping can be used for DMA request. The dev_bus_addr returned by the
^Currently (?)
> hypercall is the MFN (not the IPA). Currently Linux is using this address (via
> swiotlb) to program the DMA.
Rather than talking specifically about Linux and swiotlb I think it is
correct to say "Guests expect to be able to use the returned address for
DMA".
> When the device is protected by IOMMU the request will fail. We have to
> add 1:1 mapping in the domain p2m to allow DMA request working.
>
> This is valid because DOM0 has its memory mapped 1:1 and therefore we know
> that RAM and devices cannot clash.
Is it worth mentioning now that in the future when a domain only has
access to protected I/O devices we would instead return
dev_bus_addr==IPA and intend to drop this extra 1:1 mapping?
> The grant mapping code already handle this case for x86 PV guests. Reuse the
> same code path for ARM guest.
In particular do you mean that iommu_{,un}map_page handles the reference
counting needed when an mfn is mapped via multiple grant mapping? I
think it must be the callers of those functions. Could you say that here
please?
> diff --git a/xen/drivers/passthrough/arm/smmu.c
> b/xen/drivers/passthrough/arm/smmu.c
> index 21b4572..9f85800 100644
> --- a/xen/drivers/passthrough/arm/smmu.c
> +++ b/xen/drivers/passthrough/arm/smmu.c
> @@ -1536,6 +1536,48 @@ static void arm_smmu_iommu_domain_teardown(struct
> domain *d)
> xfree(smmu_domain);
> }
>
> +static int arm_smmu_map_page(struct domain *d, unsigned long gfn,
> + unsigned long mfn, unsigned int flags)
> +{
> + p2m_type_t t;
> +
> + /* This function should only be used by gnttab code when the domain
> + * is direct mapped and gfn == mfn.
Is gfn !+ mfn an ASSERT-worthy condition?
Is gnttab the only possible user?
> + */
> + if ( !is_domain_direct_mapped(d) || gfn != mfn )
> + return -EINVAL;
> +
> + /* We only support readable and writable flags */
> + if ( !(flags & (IOMMUF_readable | IOMMUF_writable)) )
> + return -EINVAL;
> +
> + /* The function guest_physmap_add_entry replace the current mapping
"replaces"
> + * if there is already one...
... I feel like you intended to describe a consequence of that here. I
can't see the relationship between the comment and the selection of rw
vs ro mappings.
> + */
> + t = (flags & IOMMUF_writable)? p2m_iommu_map_rw : p2m_iommu_map_ro;
> +
> + /* Grant mapping can be used for DMA request. The dev_bus_addr returned
> by
> + * the hypercall is the MFN (not the IPA). For device protected by
"Grant mappings... DMA requests... For devices" (all plural)
> + * an IOMMU, Xen needs to add a 1:1 mapping in the domain p2m to
> + * allow DMA request working.
"to allow DMA requests to work"
> + * This is only valid when the domain is directed mapped
> + */
> + return guest_physmap_add_entry(d, gfn, mfn, 0, t);
> +}
> +
> +static int arm_smmu_unmap_page(struct domain *d, unsigned long gfn)
> +{
> + /* This function should only be used by gnttab code when the domain
> + * is direct mapped
> + */
> + if ( !is_domain_direct_mapped(d) )
> + return -EINVAL;
> +
> + guest_physmap_remove_page(d, gfn, gfn, 0);
I think 0 here is really PAGE_ORDER_4K, is it? (other callers of this
function seem to be inconsistent about this)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index bd71abe..b68d5b8 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -45,6 +45,8 @@ typedef enum {
> p2m_map_foreign, /* Ram pages from foreign domain */
> p2m_grant_map_rw, /* Read/write grant mapping */
> p2m_grant_map_ro, /* Read-only grant mapping */
> + p2m_iommu_map_rw, /* Read/write iommu mapping */
> + p2m_iommu_map_ro, /* Read-only iommu mapping */
Why do we need new p2m types, rather than using e.g. the grant map type
(which I suppose is what the non-1:1 map uses)?
Could you explain the reason in the commit log too please.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |