Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"

[Arnd Bergmann]

On Wed, Mar 13, 2019 at 7:33 PM Christoph Hellwig <hch@xxxxxx> wrote:
> On Fri, Mar 08, 2019 at 05:25:57PM +0000, 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