Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"
On Wed, Mar 13, 2019 at 7:33 PM Christoph Hellwig wrote: > On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote: > > In the common case, Dom0 also contains the PV backend drivers. Those > > drivers may directly use the guest buffer in the DMA request (so a copy is > > avoided). To avoid using a bounce buffer too much, xen-swiotlb will find > > the host physical address associated to the guest buffer and will use it to > > compute the DMA address. > > > > While Dom0 kernel may only deal with 32-bit physical address, the > > hypervisor can still deal with up to 40-bit physical address. This means > > the guest memory can be allocated above the 4GB threshold. Hence why the > > dma_addr_t is always 64-bit with CONFIG_XEN=y. > > This at least makes some sense. But is it really so much better to > avoid having a 64-bit phys_addr_t? I like the way we tie phys_addr_t to the page table format, as it seems consistent to have phys_addr_t be whichever data type can be addressed through virtual memory. The main practical advantage I see in allowing phys_addr_t and dma_addr_t to be independent rather than having both of them be the same and grow to as much as is needed is that most randconfig issues I found that result from a type mismatch are for real bugs, typically in driver code that is written under the assumption that both have not only the same size but also the same binary representation for a given memory address. Arnd ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"
On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote: > In the common case, Dom0 also contains the PV backend drivers. Those > drivers may directly use the guest buffer in the DMA request (so a copy is > avoided). To avoid using a bounce buffer too much, xen-swiotlb will find > the host physical address associated to the guest buffer and will use it to > compute the DMA address. > > While Dom0 kernel may only deal with 32-bit physical address, the > hypervisor can still deal with up to 40-bit physical address. This means > the guest memory can be allocated above the 4GB threshold. Hence why the > dma_addr_t is always 64-bit with CONFIG_XEN=y. This at least makes some sense. But is it really so much better to avoid having a 64-bit phys_addr_t? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"
Hi Christoph, On 08/03/2019 15:23, Christoph Hellwig wrote: On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote: On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from the kernel point of view. How can dma_addr_t on arm have value > 32-bit when physical addresses are 32-bit only? The number of platform with IOMMU protected all DMA-capable device is not yet there. So we decided to not require IOMMU for Dom0. Instead, its memory is be directly mapped (i.e guest physical address == host physical address) and will always be below 4GB to cater the short page table case. In the common case, Dom0 also contains the PV backend drivers. Those drivers may directly use the guest buffer in the DMA request (so a copy is avoided). To avoid using a bounce buffer too much, xen-swiotlb will find the host physical address associated to the guest buffer and will use it to compute the DMA address. While Dom0 kernel may only deal with 32-bit physical address, the hypervisor can still deal with up to 40-bit physical address. This means the guest memory can be allocated above the 4GB threshold. Hence why the dma_addr_t is always 64-bit with CONFIG_XEN=y. Cheers, -- Julien Grall ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"
On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote: > On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend > on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from > the kernel point of view. How can dma_addr_t on arm have value > 32-bit when physical addresses are 32-bit only? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"
Hi Arnd,
On 3/5/19 8:16 AM, Arnd Bergmann wrote:
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote:
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:
In file included from include/linux/dma-direct.h:5,
from kernel/dma/swiotlb.c:23:
kernel/dma/swiotlb.c: In function 'swiotlb_tbl_map_single':
include/linux/dma-mapping.h:136:28: error: conversion from 'long long unsigned
int' to 'phys_addr_t' {aka 'unsigned int'} changes value from
'18446744073709551615' to '4294967295' [-Werror=overflow]
#define DMA_MAPPING_ERROR (~(dma_addr_t)0)
^
kernel/dma/swiotlb.c:544:9: note: in expansion of macro 'DMA_MAPPING_ERROR'
return DMA_MAPPING_ERROR;
The configuration that caused this is on 32-bit ARM, where the DMA address
space depends on the enabled hardware platforms, while the physical
address space depends on the type of MMU chosen (classic vs LPAE).
Are these real platforms, or random configs? Realistically I don't see a
great deal of need to support DMA_ADDR_T_64BIT for non-LPAE.
Particularly in this case since AFAIK the only selector of SWIOTLB on
Arm is Xen, and that by definition is never going to be useful on
non-LPAE hardware.
...
On Mon, Mar 4, 2019 at 11:00 PM Konrad Rzeszutek Wilk
wrote:
What about making the phys_addr_t and dma_addr_t have the same
width with some magic #ifdef hackery?
As far as I can tell, only randconfig builds see this problem, in
real systems phys_addr_t is normally the same as dma_addr_t,
and you could reasonably have a machine with a larger phys_addr_t
than dma_addr_t but wouldn't need to bother.
On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will
depend on the MMU type. So we may have phys_addr_t smaller than
dma_addr_t from the kernel point of view.
Cheers,
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"
Hi Robin,
On 3/4/19 11:56 PM, Robin Murphy wrote:
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove
SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:
In file included from include/linux/dma-direct.h:5,
from kernel/dma/swiotlb.c:23:
kernel/dma/swiotlb.c: In function 'swiotlb_tbl_map_single':
include/linux/dma-mapping.h:136:28: error: conversion from 'long long
unsigned int' to 'phys_addr_t' {aka 'unsigned int'} changes value from
'18446744073709551615' to '4294967295' [-Werror=overflow]
#define DMA_MAPPING_ERROR (~(dma_addr_t)0)
^
kernel/dma/swiotlb.c:544:9: note: in expansion of macro
'DMA_MAPPING_ERROR'
return DMA_MAPPING_ERROR;
The configuration that caused this is on 32-bit ARM, where the DMA
address
space depends on the enabled hardware platforms, while the physical
address space depends on the type of MMU chosen (classic vs LPAE).
Are these real platforms, or random configs? Realistically I don't see a
great deal of need to support DMA_ADDR_T_64BIT for non-LPAE.
This is selected by CONFIG_XEN no matter the type of MMU chosen (see
more below).
Particularly in this case since AFAIK the only selector of SWIOTLB on
Arm is Xen, and that by definition is never going to be useful on
non-LPAE hardware.
While Xen itself requires LPAE, it is still possible to run a non-LPAE
kernel in the guest. For instance, last time I checked, Debian was
shipping only non-LPAE kernel for Arm32.
On Arm, swiotlb is only used by the hardware domain (aka Dom0) to allow
DMA in memory mapped from other guest. So the returned DMA address may
be 64-bit. Hence why we select DMA_ADDR_T_64BIT above.
Cheers,
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
