Re: xen-swiotlb issue when NVMe driver is enabled in Dom0 on ARM

[Christoph Hellwig <hch@xxxxxx>]

On Fri, Apr 22, 2022 at 01:29:54PM -0700, Stefano Stabellini wrote:
> It is great to remove xen_alloc_coherent_pages/xen_free_coherent_pages
> for ARM. We can safely remove them because on ARM we can only use
> swiotlb-xen when the domain is 1:1 mapped. So it is impossible to get
> into a situation where memory allocated expected to be contiguous is not
> actually contiguous.
> 
> So, from an ARM point of view, it is great. However,
> DMA_ATTR_NO_KERNEL_MAPPING wouldn't work on x86 still? I don't know if
> matters.

It works by ignoring it, just like it works for most of the other
DMA OPS instance.  The problem with the existing xen swiotlb case
is it tries to interpret what is returned by dma_direct_alloc.
Driver must not do that per the API contract and just use the DMA
handle while using the return value as a cookie only. It is a odd
API and I plan to remove it eventually.

> Then a small NIT: the declaration of xen_create_contiguous_region and
> xen_destroy_contiguous_region should be moved away from
> include/xen/xen-ops.h to an arch/x86 specific header. For instance to
> arch/x86/include/asm/xen/swiotlb-xen.h. Or at least the #ifdef in
> include/xen/xen-ops.h should change, currently it is:
> 
> #if defined(CONFIG_XEN_PV) || defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
>                               unsigned int address_bits,
>                               dma_addr_t *dma_handle);
> void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order);
> #endif

I'll resend a cleaned up version in a bit.