All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: David Gibson <david@gibson.dropbear.id.au>,
	Ram Pai <linuxram@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org,
	virtualization@lists.linux-foundation.org,
	benh@kernel.crashing.org, mpe@ellerman.id.au, paulus@ozlabs.org,
	mdroth@linux.vnet.ibm.com, aik@linux.ibm.com,
	paul.burton@mips.com, b.zolnierkie@samsung.com,
	m.szyprowski@samsung.com, hch@lst.de, jasowang@redhat.com,
	andmike@us.ibm.com, sukadev@linux.vnet.ibm.com
Subject: Re: [PATCH 1/2] dma-mapping: Add dma_addr_is_phys_addr()
Date: Mon, 14 Oct 2019 11:29:24 +0100	[thread overview]
Message-ID: <37609731-5539-b906-aa94-2ef0242795ac@arm.com> (raw)
In-Reply-To: <20191014045139.GN4080@umbus.fritz.box>

On 14/10/2019 05:51, David Gibson wrote:
> On Fri, Oct 11, 2019 at 06:25:18PM -0700, Ram Pai wrote:
>> From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>>
>> In order to safely use the DMA API, virtio needs to know whether DMA
>> addresses are in fact physical addresses and for that purpose,
>> dma_addr_is_phys_addr() is introduced.
>>
>> cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> cc: David Gibson <david@gibson.dropbear.id.au>
>> cc: Michael Ellerman <mpe@ellerman.id.au>
>> cc: Paul Mackerras <paulus@ozlabs.org>
>> cc: Michael Roth <mdroth@linux.vnet.ibm.com>
>> cc: Alexey Kardashevskiy <aik@linux.ibm.com>
>> cc: Paul Burton <paul.burton@mips.com>
>> cc: Robin Murphy <robin.murphy@arm.com>
>> cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>> cc: Marek Szyprowski <m.szyprowski@samsung.com>
>> cc: Christoph Hellwig <hch@lst.de>
>> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
>> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> 
> The change itself looks ok, so
> 
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> 
> However, I would like to see the commit message (and maybe the inline
> comments) expanded a bit on what the distinction here is about.  Some
> of the text from the next patch would be suitable, about DMA addresses
> usually being in a different address space but not in the case of
> bounce buffering.

Right, this needs a much tighter definition. "DMA address happens to be 
a valid physical address" is true of various IOMMU setups too, but I 
can't believe it's meaningful in such cases.

If what you actually want is "DMA is direct or SWIOTLB" - i.e. "DMA 
address is physical address of DMA data (not necessarily the original 
buffer)" - wouldn't dma_is_direct() suffice?

Robin.

>> ---
>>   arch/powerpc/include/asm/dma-mapping.h | 21 +++++++++++++++++++++
>>   arch/powerpc/platforms/pseries/Kconfig |  1 +
>>   include/linux/dma-mapping.h            | 20 ++++++++++++++++++++
>>   kernel/dma/Kconfig                     |  3 +++
>>   4 files changed, 45 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
>> index 565d6f7..f92c0a4b 100644
>> --- a/arch/powerpc/include/asm/dma-mapping.h
>> +++ b/arch/powerpc/include/asm/dma-mapping.h
>> @@ -5,6 +5,8 @@
>>   #ifndef _ASM_DMA_MAPPING_H
>>   #define _ASM_DMA_MAPPING_H
>>   
>> +#include <asm/svm.h>
>> +
>>   static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
>>   {
>>   	/* We don't handle the NULL dev case for ISA for now. We could
>> @@ -15,4 +17,23 @@ static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
>>   	return NULL;
>>   }
>>   
>> +#ifdef CONFIG_ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +/**
>> + * dma_addr_is_phys_addr - check whether a device DMA address is a physical
>> + *		address
>> + * @dev:	device to check
>> + *
>> + * Returns %true if any DMA address for this device happens to also be a valid
>> + * physical address (not necessarily of the same page).
>> + */
>> +static inline bool dma_addr_is_phys_addr(struct device *dev)
>> +{
>> +	/*
>> +	 * Secure guests always use the SWIOTLB, therefore DMA addresses are
>> +	 * actually the physical address of the bounce buffer.
>> +	 */
>> +	return is_secure_guest();
>> +}
>> +#endif
>> +
>>   #endif	/* _ASM_DMA_MAPPING_H */
>> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
>> index 9e35cdd..0108150 100644
>> --- a/arch/powerpc/platforms/pseries/Kconfig
>> +++ b/arch/powerpc/platforms/pseries/Kconfig
>> @@ -152,6 +152,7 @@ config PPC_SVM
>>   	select SWIOTLB
>>   	select ARCH_HAS_MEM_ENCRYPT
>>   	select ARCH_HAS_FORCE_DMA_UNENCRYPTED
>> +	select ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>>   	help
>>   	 There are certain POWER platforms which support secure guests using
>>   	 the Protected Execution Facility, with the help of an Ultravisor
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index f7d1eea..6df5664 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -693,6 +693,26 @@ static inline bool dma_addressing_limited(struct device *dev)
>>   			    dma_get_required_mask(dev);
>>   }
>>   
>> +#ifndef CONFIG_ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +/**
>> + * dma_addr_is_phys_addr - check whether a device DMA address is a physical
>> + *		address
>> + * @dev:	device to check
>> + *
>> + * Returns %true if any DMA address for this device happens to also be a valid
>> + * physical address (not necessarily of the same page).
>> + */
>> +static inline bool dma_addr_is_phys_addr(struct device *dev)
>> +{
>> +	/*
>> +	 * Except in very specific setups, DMA addresses exist in a different
>> +	 * address space from CPU physical addresses and cannot be directly used
>> +	 * to reference system memory.
>> +	 */
>> +	return false;
>> +}
>> +#endif
>> +
>>   #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
>>   void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>>   		const struct iommu_ops *iommu, bool coherent);
>> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
>> index 9decbba..6209b46 100644
>> --- a/kernel/dma/Kconfig
>> +++ b/kernel/dma/Kconfig
>> @@ -51,6 +51,9 @@ config ARCH_HAS_DMA_MMAP_PGPROT
>>   config ARCH_HAS_FORCE_DMA_UNENCRYPTED
>>   	bool
>>   
>> +config ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +	bool
>> +
>>   config DMA_NONCOHERENT_CACHE_SYNC
>>   	bool
>>   
> 

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: David Gibson <david@gibson.dropbear.id.au>,
	Ram Pai <linuxram@us.ibm.com>
Cc: andmike@us.ibm.com, mdroth@linux.vnet.ibm.com,
	b.zolnierkie@samsung.com, jasowang@redhat.com, aik@linux.ibm.com,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, paul.burton@mips.com,
	sukadev@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,
	hch@lst.de, m.szyprowski@samsung.com
Subject: Re: [PATCH 1/2] dma-mapping: Add dma_addr_is_phys_addr()
Date: Mon, 14 Oct 2019 11:29:24 +0100	[thread overview]
Message-ID: <37609731-5539-b906-aa94-2ef0242795ac@arm.com> (raw)
In-Reply-To: <20191014045139.GN4080@umbus.fritz.box>

On 14/10/2019 05:51, David Gibson wrote:
> On Fri, Oct 11, 2019 at 06:25:18PM -0700, Ram Pai wrote:
>> From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>>
>> In order to safely use the DMA API, virtio needs to know whether DMA
>> addresses are in fact physical addresses and for that purpose,
>> dma_addr_is_phys_addr() is introduced.
>>
>> cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> cc: David Gibson <david@gibson.dropbear.id.au>
>> cc: Michael Ellerman <mpe@ellerman.id.au>
>> cc: Paul Mackerras <paulus@ozlabs.org>
>> cc: Michael Roth <mdroth@linux.vnet.ibm.com>
>> cc: Alexey Kardashevskiy <aik@linux.ibm.com>
>> cc: Paul Burton <paul.burton@mips.com>
>> cc: Robin Murphy <robin.murphy@arm.com>
>> cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>> cc: Marek Szyprowski <m.szyprowski@samsung.com>
>> cc: Christoph Hellwig <hch@lst.de>
>> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
>> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> 
> The change itself looks ok, so
> 
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> 
> However, I would like to see the commit message (and maybe the inline
> comments) expanded a bit on what the distinction here is about.  Some
> of the text from the next patch would be suitable, about DMA addresses
> usually being in a different address space but not in the case of
> bounce buffering.

Right, this needs a much tighter definition. "DMA address happens to be 
a valid physical address" is true of various IOMMU setups too, but I 
can't believe it's meaningful in such cases.

If what you actually want is "DMA is direct or SWIOTLB" - i.e. "DMA 
address is physical address of DMA data (not necessarily the original 
buffer)" - wouldn't dma_is_direct() suffice?

Robin.

>> ---
>>   arch/powerpc/include/asm/dma-mapping.h | 21 +++++++++++++++++++++
>>   arch/powerpc/platforms/pseries/Kconfig |  1 +
>>   include/linux/dma-mapping.h            | 20 ++++++++++++++++++++
>>   kernel/dma/Kconfig                     |  3 +++
>>   4 files changed, 45 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
>> index 565d6f7..f92c0a4b 100644
>> --- a/arch/powerpc/include/asm/dma-mapping.h
>> +++ b/arch/powerpc/include/asm/dma-mapping.h
>> @@ -5,6 +5,8 @@
>>   #ifndef _ASM_DMA_MAPPING_H
>>   #define _ASM_DMA_MAPPING_H
>>   
>> +#include <asm/svm.h>
>> +
>>   static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
>>   {
>>   	/* We don't handle the NULL dev case for ISA for now. We could
>> @@ -15,4 +17,23 @@ static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
>>   	return NULL;
>>   }
>>   
>> +#ifdef CONFIG_ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +/**
>> + * dma_addr_is_phys_addr - check whether a device DMA address is a physical
>> + *		address
>> + * @dev:	device to check
>> + *
>> + * Returns %true if any DMA address for this device happens to also be a valid
>> + * physical address (not necessarily of the same page).
>> + */
>> +static inline bool dma_addr_is_phys_addr(struct device *dev)
>> +{
>> +	/*
>> +	 * Secure guests always use the SWIOTLB, therefore DMA addresses are
>> +	 * actually the physical address of the bounce buffer.
>> +	 */
>> +	return is_secure_guest();
>> +}
>> +#endif
>> +
>>   #endif	/* _ASM_DMA_MAPPING_H */
>> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
>> index 9e35cdd..0108150 100644
>> --- a/arch/powerpc/platforms/pseries/Kconfig
>> +++ b/arch/powerpc/platforms/pseries/Kconfig
>> @@ -152,6 +152,7 @@ config PPC_SVM
>>   	select SWIOTLB
>>   	select ARCH_HAS_MEM_ENCRYPT
>>   	select ARCH_HAS_FORCE_DMA_UNENCRYPTED
>> +	select ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>>   	help
>>   	 There are certain POWER platforms which support secure guests using
>>   	 the Protected Execution Facility, with the help of an Ultravisor
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index f7d1eea..6df5664 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -693,6 +693,26 @@ static inline bool dma_addressing_limited(struct device *dev)
>>   			    dma_get_required_mask(dev);
>>   }
>>   
>> +#ifndef CONFIG_ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +/**
>> + * dma_addr_is_phys_addr - check whether a device DMA address is a physical
>> + *		address
>> + * @dev:	device to check
>> + *
>> + * Returns %true if any DMA address for this device happens to also be a valid
>> + * physical address (not necessarily of the same page).
>> + */
>> +static inline bool dma_addr_is_phys_addr(struct device *dev)
>> +{
>> +	/*
>> +	 * Except in very specific setups, DMA addresses exist in a different
>> +	 * address space from CPU physical addresses and cannot be directly used
>> +	 * to reference system memory.
>> +	 */
>> +	return false;
>> +}
>> +#endif
>> +
>>   #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
>>   void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>>   		const struct iommu_ops *iommu, bool coherent);
>> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
>> index 9decbba..6209b46 100644
>> --- a/kernel/dma/Kconfig
>> +++ b/kernel/dma/Kconfig
>> @@ -51,6 +51,9 @@ config ARCH_HAS_DMA_MMAP_PGPROT
>>   config ARCH_HAS_FORCE_DMA_UNENCRYPTED
>>   	bool
>>   
>> +config ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +	bool
>> +
>>   config DMA_NONCOHERENT_CACHE_SYNC
>>   	bool
>>   
> 

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: David Gibson <david@gibson.dropbear.id.au>,
	Ram Pai <linuxram@us.ibm.com>
Cc: andmike@us.ibm.com, mdroth@linux.vnet.ibm.com,
	b.zolnierkie@samsung.com, mpe@ellerman.id.au,
	jasowang@redhat.com, aik@linux.ibm.com,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, paulus@ozlabs.org,
	iommu@lists.linux-foundation.org, paul.burton@mips.com,
	benh@kernel.crashing.org, sukadev@linux.vnet.ibm.com,
	linuxppc-dev@lists.ozlabs.org, hch@lst.de
Subject: Re: [PATCH 1/2] dma-mapping: Add dma_addr_is_phys_addr()
Date: Mon, 14 Oct 2019 11:29:24 +0100	[thread overview]
Message-ID: <37609731-5539-b906-aa94-2ef0242795ac@arm.com> (raw)
In-Reply-To: <20191014045139.GN4080@umbus.fritz.box>

On 14/10/2019 05:51, David Gibson wrote:
> On Fri, Oct 11, 2019 at 06:25:18PM -0700, Ram Pai wrote:
>> From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>>
>> In order to safely use the DMA API, virtio needs to know whether DMA
>> addresses are in fact physical addresses and for that purpose,
>> dma_addr_is_phys_addr() is introduced.
>>
>> cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> cc: David Gibson <david@gibson.dropbear.id.au>
>> cc: Michael Ellerman <mpe@ellerman.id.au>
>> cc: Paul Mackerras <paulus@ozlabs.org>
>> cc: Michael Roth <mdroth@linux.vnet.ibm.com>
>> cc: Alexey Kardashevskiy <aik@linux.ibm.com>
>> cc: Paul Burton <paul.burton@mips.com>
>> cc: Robin Murphy <robin.murphy@arm.com>
>> cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>> cc: Marek Szyprowski <m.szyprowski@samsung.com>
>> cc: Christoph Hellwig <hch@lst.de>
>> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
>> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> 
> The change itself looks ok, so
> 
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> 
> However, I would like to see the commit message (and maybe the inline
> comments) expanded a bit on what the distinction here is about.  Some
> of the text from the next patch would be suitable, about DMA addresses
> usually being in a different address space but not in the case of
> bounce buffering.

Right, this needs a much tighter definition. "DMA address happens to be 
a valid physical address" is true of various IOMMU setups too, but I 
can't believe it's meaningful in such cases.

If what you actually want is "DMA is direct or SWIOTLB" - i.e. "DMA 
address is physical address of DMA data (not necessarily the original 
buffer)" - wouldn't dma_is_direct() suffice?

Robin.

>> ---
>>   arch/powerpc/include/asm/dma-mapping.h | 21 +++++++++++++++++++++
>>   arch/powerpc/platforms/pseries/Kconfig |  1 +
>>   include/linux/dma-mapping.h            | 20 ++++++++++++++++++++
>>   kernel/dma/Kconfig                     |  3 +++
>>   4 files changed, 45 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
>> index 565d6f7..f92c0a4b 100644
>> --- a/arch/powerpc/include/asm/dma-mapping.h
>> +++ b/arch/powerpc/include/asm/dma-mapping.h
>> @@ -5,6 +5,8 @@
>>   #ifndef _ASM_DMA_MAPPING_H
>>   #define _ASM_DMA_MAPPING_H
>>   
>> +#include <asm/svm.h>
>> +
>>   static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
>>   {
>>   	/* We don't handle the NULL dev case for ISA for now. We could
>> @@ -15,4 +17,23 @@ static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
>>   	return NULL;
>>   }
>>   
>> +#ifdef CONFIG_ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +/**
>> + * dma_addr_is_phys_addr - check whether a device DMA address is a physical
>> + *		address
>> + * @dev:	device to check
>> + *
>> + * Returns %true if any DMA address for this device happens to also be a valid
>> + * physical address (not necessarily of the same page).
>> + */
>> +static inline bool dma_addr_is_phys_addr(struct device *dev)
>> +{
>> +	/*
>> +	 * Secure guests always use the SWIOTLB, therefore DMA addresses are
>> +	 * actually the physical address of the bounce buffer.
>> +	 */
>> +	return is_secure_guest();
>> +}
>> +#endif
>> +
>>   #endif	/* _ASM_DMA_MAPPING_H */
>> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
>> index 9e35cdd..0108150 100644
>> --- a/arch/powerpc/platforms/pseries/Kconfig
>> +++ b/arch/powerpc/platforms/pseries/Kconfig
>> @@ -152,6 +152,7 @@ config PPC_SVM
>>   	select SWIOTLB
>>   	select ARCH_HAS_MEM_ENCRYPT
>>   	select ARCH_HAS_FORCE_DMA_UNENCRYPTED
>> +	select ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>>   	help
>>   	 There are certain POWER platforms which support secure guests using
>>   	 the Protected Execution Facility, with the help of an Ultravisor
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index f7d1eea..6df5664 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -693,6 +693,26 @@ static inline bool dma_addressing_limited(struct device *dev)
>>   			    dma_get_required_mask(dev);
>>   }
>>   
>> +#ifndef CONFIG_ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +/**
>> + * dma_addr_is_phys_addr - check whether a device DMA address is a physical
>> + *		address
>> + * @dev:	device to check
>> + *
>> + * Returns %true if any DMA address for this device happens to also be a valid
>> + * physical address (not necessarily of the same page).
>> + */
>> +static inline bool dma_addr_is_phys_addr(struct device *dev)
>> +{
>> +	/*
>> +	 * Except in very specific setups, DMA addresses exist in a different
>> +	 * address space from CPU physical addresses and cannot be directly used
>> +	 * to reference system memory.
>> +	 */
>> +	return false;
>> +}
>> +#endif
>> +
>>   #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
>>   void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>>   		const struct iommu_ops *iommu, bool coherent);
>> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
>> index 9decbba..6209b46 100644
>> --- a/kernel/dma/Kconfig
>> +++ b/kernel/dma/Kconfig
>> @@ -51,6 +51,9 @@ config ARCH_HAS_DMA_MMAP_PGPROT
>>   config ARCH_HAS_FORCE_DMA_UNENCRYPTED
>>   	bool
>>   
>> +config ARCH_HAS_DMA_ADDR_IS_PHYS_ADDR
>> +	bool
>> +
>>   config DMA_NONCOHERENT_CACHE_SYNC
>>   	bool
>>   
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2019-10-14 10:29 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-12  1:25 [PATCH 0/2] virtio: Support encrypted memory on powerpc secure guests Ram Pai
2019-10-12  1:25 ` Ram Pai
2019-10-12  1:25 ` Ram Pai
2019-10-12  1:25 ` [PATCH 1/2] dma-mapping: Add dma_addr_is_phys_addr() Ram Pai
2019-10-12  1:25   ` Ram Pai
2019-10-12  1:25   ` Ram Pai
2019-10-12  1:25   ` [PATCH 2/2] virtio_ring: Use DMA API if memory is encrypted Ram Pai
2019-10-12  1:25     ` Ram Pai
2019-10-12  1:25     ` Ram Pai
2019-10-14  4:52     ` David Gibson
2019-10-14  4:52       ` David Gibson
2019-10-14  4:52       ` David Gibson
2019-10-14  4:52     ` David Gibson
2019-10-15  7:35     ` Christoph Hellwig
2019-10-15  7:35     ` Christoph Hellwig
2019-10-15  7:35       ` Christoph Hellwig
2019-10-15  7:35       ` Christoph Hellwig
2019-10-16  7:55       ` Ram Pai
2019-10-16  7:55       ` Ram Pai
2019-10-16  7:55         ` Ram Pai
2019-10-16  7:55         ` Ram Pai
2019-10-17  2:33       ` Jason Wang
2019-10-17  2:33       ` Jason Wang
2019-10-17  2:33         ` Jason Wang
2019-10-17  2:33         ` Jason Wang
2019-10-21  8:36       ` David Gibson
2019-10-21  8:36         ` David Gibson
2019-10-21  8:36         ` David Gibson
2019-10-21  8:36       ` David Gibson
2019-10-12  1:25   ` Ram Pai
2019-10-14  4:51   ` [PATCH 1/2] dma-mapping: Add dma_addr_is_phys_addr() David Gibson
2019-10-14  4:51     ` David Gibson
2019-10-14  4:51     ` David Gibson
2019-10-14 10:29     ` Robin Murphy
2019-10-14 10:29     ` Robin Murphy [this message]
2019-10-14 10:29       ` Robin Murphy
2019-10-14 10:29       ` Robin Murphy
2019-10-15  7:30       ` Ram Pai
2019-10-15  7:30         ` Ram Pai
2019-10-15  7:30         ` Ram Pai
2019-10-15  7:30         ` Ram Pai
2019-10-15  7:31       ` Christoph Hellwig
2019-10-15  7:31       ` Christoph Hellwig
2019-10-15  7:31         ` Christoph Hellwig
2019-10-15  7:31         ` Christoph Hellwig
2019-10-14  4:51   ` David Gibson
2019-10-12  1:25 ` Ram Pai
2019-10-12  1:36 ` [PATCH 0/2] virtio: Support encrypted memory on powerpc secure guests Ram Pai
2019-10-12  1:36 ` Ram Pai
2019-10-12  1:36   ` Ram Pai
2019-10-12  1:36   ` Ram Pai

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=37609731-5539-b906-aa94-2ef0242795ac@arm.com \
    --to=robin.murphy@arm.com \
    --cc=aik@linux.ibm.com \
    --cc=andmike@us.ibm.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=benh@kernel.crashing.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=linuxram@us.ibm.com \
    --cc=m.szyprowski@samsung.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=paul.burton@mips.com \
    --cc=paulus@ozlabs.org \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.