iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: Eric Auger <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	marc.zyngier-5wv7dgnIgG8@public.gmane.org,
	alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	will.deacon-5wv7dgnIgG8@public.gmane.org,
	joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org,
	tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
	jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: drjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Manish.Jaggi-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org,
	p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	yehuday-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org
Subject: Re: [RFC 05/11] iommu/dma: iommu_dma_(un)map_mixed
Date: Fri, 30 Sep 2016 14:24:40 +0100	[thread overview]
Message-ID: <1b1b30b3-4199-9e18-362c-b8bc9d45277d@arm.com> (raw)
In-Reply-To: <1475009318-2617-6-git-send-email-eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hi Eric,

On 27/09/16 21:48, Eric Auger wrote:
> iommu_dma_map_mixed and iommu_dma_unmap_mixed operate on
> IOMMU_DOMAIN_MIXED typed domains. On top of standard iommu_map/unmap
> they reserve the IOVA window to prevent the iova allocator to
> allocate in those areas.
> 
> Signed-off-by: Eric Auger <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  drivers/iommu/dma-iommu.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/dma-iommu.h | 18 ++++++++++++++++++
>  2 files changed, 66 insertions(+)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 04bbc85..db21143 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -759,3 +759,51 @@ int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
>  	return 0;
>  }
>  EXPORT_SYMBOL(iommu_get_dma_msi_region_cookie);
> +
> +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> +			phys_addr_t paddr, size_t size, int prot)
> +{
> +	struct iova_domain *iovad;
> +	unsigned long lo, hi;
> +	int ret;
> +
> +	if (domain->type != IOMMU_DOMAIN_MIXED)
> +		return -EINVAL;
> +
> +	if (!domain->iova_cookie)
> +		return -EINVAL;
> +
> +	iovad = cookie_iovad(domain);
> +
> +	lo = iova_pfn(iovad, iova);
> +	hi = iova_pfn(iovad, iova + size - 1);
> +	reserve_iova(iovad, lo, hi);

This can't work reliably - reserve_iova() will (for good reason) merge
any adjacent or overlapping entries, so any unmap is liable to free more
IOVA space than actually gets unmapped, and things will get subtly out
of sync and go wrong later.

The more general issue with this whole approach, though, is that it
effectively rules out userspace doing guest memory hotplug or similar,
and I'm not we want to paint ourselves into that corner. Basically, as
soon as a device is attached to a guest, the entirety of the unallocated
IPA space becomes reserved, and userspace can never add anything further
to it, because any given address *might* be in use for an MSI mapping.

I think it still makes most sense to stick with the original approach of
cooperating with userspace to reserve a bounded area - it's just that we
can then let automatic mapping take care of itself within that area.

Speaking of which, I've realised the same fundamental reservation
problem already applies to PCI without ACS, regardless of MSIs. I just
tried on my Juno with guest memory placed at 0x4000000000, (i.e.
matching the host PA of the 64-bit PCI window), and sure enough when the
guest kicks off some DMA on the passed-through NIC, the root complex
interprets the guest IPA as (unsupported) peer-to-peer DMA to a BAR
claimed by the video card, and it fails. I guess this doesn't get hit in
practice on x86 because the guest memory map is unlikely to be much
different from the host's.

It seems like we basically need a general way of communicating fixed and
movable host reservations to userspace :/

Robin.

> +	ret = iommu_map(domain, iova, paddr, size, prot);
> +	if (ret)
> +		free_iova(iovad, lo);
> +	return ret;
> +}
> +EXPORT_SYMBOL(iommu_dma_map_mixed);
> +
> +size_t iommu_dma_unmap_mixed(struct iommu_domain *domain, unsigned long iova,
> +			     size_t size)
> +{
> +	struct iova_domain *iovad;
> +	unsigned long lo;
> +	size_t ret;
> +
> +	if (domain->type != IOMMU_DOMAIN_MIXED)
> +		return -EINVAL;
> +
> +	if (!domain->iova_cookie)
> +		return -EINVAL;
> +
> +	iovad = cookie_iovad(domain);
> +	lo = iova_pfn(iovad, iova);
> +
> +	ret = iommu_unmap(domain, iova, size);
> +	if (ret == size)
> +		free_iova(iovad, lo);
> +	return ret;
> +}
> +EXPORT_SYMBOL(iommu_dma_unmap_mixed);
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 1c55413..f2aa855 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -70,6 +70,12 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>  int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
>  		dma_addr_t base, u64 size);
>  
> +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> +			phys_addr_t paddr, size_t size, int prot);
> +
> +size_t iommu_dma_unmap_mixed(struct iommu_domain *domain, unsigned long iova,
> +			     size_t size);
> +
>  #else
>  
>  struct iommu_domain;
> @@ -99,6 +105,18 @@ static inline int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
>  	return -ENODEV;
>  }
>  
> +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> +			phys_addr_t paddr, size_t size, int prot)
> +{
> +	return -ENODEV;
> +}
> +
> +size_t iommu_dma_unmap_mixed(struct iommu_domain *domain, unsigned long iova,
> +			     size_t size)
> +{
> +	return -ENODEV;
> +}
> +
>  #endif	/* CONFIG_IOMMU_DMA */
>  #endif	/* __KERNEL__ */
>  #endif	/* __DMA_IOMMU_H */
> 

  parent reply	other threads:[~2016-09-30 13:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-27 20:48 [RFC 00/11] KVM PCIe/MSI passthrough on ARM/ARM64: re-design with transparent MSI mapping Eric Auger
     [not found] ` <1475009318-2617-1-git-send-email-eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-27 20:48   ` [RFC 01/11] iommu: Add iommu_domain_msi_geometry and DOMAIN_ATTR_MSI_GEOMETRY Eric Auger
2016-09-27 20:48   ` [RFC 02/11] iommu: Introduce IOMMU_CAP_TRANSLATE_MSI capability Eric Auger
2016-09-27 20:48   ` [RFC 03/11] iommu: Introduce IOMMU_DOMAIN_MIXED Eric Auger
2016-09-27 20:48   ` [RFC 04/11] iommu/dma: Allow MSI-only cookies Eric Auger
2016-09-27 20:48   ` [RFC 05/11] iommu/dma: iommu_dma_(un)map_mixed Eric Auger
     [not found]     ` <1475009318-2617-6-git-send-email-eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-30 13:24       ` Robin Murphy [this message]
     [not found]         ` <1b1b30b3-4199-9e18-362c-b8bc9d45277d-5wv7dgnIgG8@public.gmane.org>
2016-10-02  9:56           ` Christoffer Dall
2016-10-04 17:18             ` Robin Murphy
2016-10-04 17:37               ` Auger Eric
2016-10-03  9:38           ` Auger Eric
2016-09-27 20:48   ` [RFC 06/11] iommu/arm-smmu: Allow IOMMU_DOMAIN_MIXED domain allocation Eric Auger
2016-09-27 20:48   ` [RFC 07/11] iommu: Use IOMMU_DOMAIN_MIXED typed domain when IOMMU translates MSI Eric Auger
2016-09-27 20:48   ` [RFC 08/11] vfio/type1: Sets the IOVA window in case MSI IOVA need to be allocated Eric Auger
2016-09-27 20:48   ` [RFC 09/11] vfio/type1: Reserve IOVAs for IOMMU_DOMAIN_MIXED domains Eric Auger
2016-09-27 20:48   ` [RFC 10/11] iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP Eric Auger
2016-09-27 20:48   ` [RFC 11/11] iommu/arm-smmu: Advertise IOMMU_CAP_TRANSLATE_MSI Eric Auger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1b1b30b3-4199-9e18-362c-b8bc9d45277d@arm.com \
    --to=robin.murphy-5wv7dgnigg8@public.gmane.org \
    --cc=Manish.Jaggi-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
    --cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=drjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
    --cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
    --cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    --cc=yehuday-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).