[PATCH kernel v3 09/22] powerpc/pseries/iommu: Force default DMA window removal

[David Gibson]

On Tue, Nov 13, 2018 at 07:28:10PM +1100, Alexey Kardashevskiy wrote:
> It is quite common for a device to support more than 32bit but less than
> 64bit for DMA, for example, GPUs often support 42..50bits. However
> the pseries platform only allows huge DMA window (the one which allows
> the use of more than 2GB of DMA space) for 64bit-capable devices mostly
> because:
> 
> 1. we may have 32bit and >32bit devices on the same IOMMU domain and
> we cannot place the new big window where the 32bit one is located;
> 
> 2. the existing hardware only supports the second window at very high
> offset of 1<<59 == 0x0800.0000.0000.0000.
> 
> So in order to allow 33..59bit DMA, we have to remove the default DMA
> window and place a huge one there instead.
> 
> The PAPR spec says that the platform may decide not to use the default
> window and remove it using DDW RTAS calls. There are few possible ways
> for the platform to decide:
> 
> 1. look at the device IDs and decide in advance that such and such
> devices are capable of more than 32bit DMA (powernv's sketchy bypass
> does something like this - it drops the default window if all devices
> on the PE are from the same vendor) - this is not great as involves
> guessing because, unlike sketchy bypass, the GPU case involves 2 vendor
> ids and does not scale;
> 
> 2. advertise 1 available DMA window in the hypervisor via
> ibm,query-pe-dma-window so the pseries platform could take it as a clue
> that if more bits for DMA are needed, it has to remove the default
> window - this is not great as it is implicit clue rather than direct
> instruction;
> 
> 3. removing the default DMA window at all it not really an option as
> PAPR mandates its presense at the guest boot time;
> 
> 4. make the hypervisor explicitly tell the guest that the default window
> is better be removed so the guest does not have to think hard and can
> simply do what requested and this is what this patch does.

This approach only makes sense if the hypervisor has better
information as to what to do that the guest does.  It's not clear to
me why that would be the case.  Isn't the DMA capabilities of the
device something the driver should know, in which case it can decide
based on that?

> 
> This makes use of the latter approach and exploits a new
> "qemu,dma-force-remove-default" flag in a vPHB.
> 
> Signed-off-by: Alexey Kardashevskiy <aik at ozlabs.ru>
> ---
>  arch/powerpc/platforms/pseries/iommu.c | 28 +++++++++++++++++++++++---
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> index 9ece42f..78473ac 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -54,6 +54,7 @@
>  #include "pseries.h"
>  
>  #define DDW_INVALID_OFFSET	((uint64_t)-1)
> +#define DDW_INVALID_LIOBN	((uint32_t)-1)
>  
>  static struct iommu_table_group *iommu_pseries_alloc_group(int node)
>  {
> @@ -977,7 +978,8 @@ static LIST_HEAD(failed_ddw_pdn_list);
>   *
>   * returns the dma offset for use by dma_set_mask
>   */
> -static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
> +static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn,
> +		u32 default_liobn)
>  {
>  	int len, ret;
>  	struct ddw_query_response query;
> @@ -1022,6 +1024,16 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
>  	if (ret)
>  		goto out_failed;
>  
> +	/*
> +	 * The device tree has a request to force remove the default window,
> +	 * do this.
> +	 */
> +	if (default_liobn != DDW_INVALID_LIOBN && (!ddw_avail[2] ||
> +			rtas_call(ddw_avail[2], 1, 1, NULL, default_liobn))) {
> +		dev_dbg(&dev->dev, "Could not remove window");
> +		goto out_failed;
> +	}
> +
>         /*
>  	 * Query if there is a second window of size to map the
>  	 * whole partition.  Query returns number of windows, largest
> @@ -1212,7 +1224,7 @@ static int dma_set_mask_pSeriesLP(struct device *dev, u64 dma_mask)
>  	pdev = to_pci_dev(dev);
>  
>  	/* only attempt to use a new window if 64-bit DMA is requested */
> -	if (!disable_ddw && dma_mask == DMA_BIT_MASK(64)) {
> +	if (!disable_ddw && dma_mask > DMA_BIT_MASK(32)) {
>  		dn = pci_device_to_OF_node(pdev);
>  		dev_dbg(dev, "node is %pOF\n", dn);
>  
> @@ -1229,7 +1241,17 @@ static int dma_set_mask_pSeriesLP(struct device *dev, u64 dma_mask)
>  				break;
>  		}
>  		if (pdn && PCI_DN(pdn)) {
> -			dma_offset = enable_ddw(pdev, pdn);
> +			u32 liobn = DDW_INVALID_LIOBN;
> +			int ret = of_device_is_compatible(pdn, "IBM,npu-vphb");
> +
> +			if (ret) {
> +				dma_window = of_get_property(pdn,
> +						"ibm,dma-window", NULL);
> +				if (dma_window)
> +					liobn = be32_to_cpu(dma_window[0]);
> +			}
> +
> +			dma_offset = enable_ddw(pdev, pdn, liobn);
>  			if (dma_offset != DDW_INVALID_OFFSET) {
>  				dev_info(dev, "Using 64-bit direct DMA at offset %llx\n", dma_offset);
>  				set_dma_offset(dev, dma_offset);

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20181116/b15bdf19/attachment.sig>