On Tue, 2 Jun 2020, Corey Minyard wrote:
> Snip
> 
> > > > > > whether
> > > > > > this was already done:
> > > > > >      1) Does the kernel boot on baremetal (i.e without Xen)? This should
> > > > > > help
> > > > > > to confirm whether the bug is Xen is related.
> > > > > 
> > > > > Yes it boots
> > > > > 
> > > > > >      2) Swiotlb should not be necessary for basic dom0 boot on Arm. Did
> > > > > > you try
> > > > > > to disable it? This should help to confirm whether swiotlb is the
> > > > > > problem or
> > > > > > not.
> > > > > 
> > > > > It boots disabling swiotlb-xen
> > > > 
> > > > Thank you for the answer! swiotlb-xen should basically be a NOP for dom0. So
> > > > this suggests swiotlb is doing some transformation on the DMA address.
> > > > 
> > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to assume
> > > > the DMA address space and CPU address space is the same. Is RPI using the
> > > > same address space?
> > > 
> > > Another question, is the DMA request bounced? If so, are we sure the bounce
> > > buffer is in the first GB?
> > 
> > Yes, it is. This is actually where we spent the last few days, and I
> > found another little related bug in the initialization of the
> > swiotlb-xen but now I am sure the memory is under 1GB (0x34000000-0x38000000)
> 
> Was anything ever resolved on this issue?  It just kind of ended for me,
> and I looked in the main kernel and didn't find anything that looked
> related.

Yes, we have a patch series on the list for the Linux kernel to fix this
issue but it hasn't been merged yet:

https://marc.info/?l=linux-kernel&m=159001831406263&w=2