[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Upstream Dom0 DRM problems regarding swiotlb

On Fri, Feb 15, 2019 at 12:57 AM Juergen Gross <jgross@xxxxxxxx> wrote:
> On 14/02/2019 18:57, Christoph Hellwig wrote:
> > On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote:
> >>> The thing which is different between Xen PV guests and most others (all
> >>> others(?), now that Lguest and UML have been dropped) is that what Linux
> >>> thinks of as PFN $N isn't necessarily adjacent to PFN $N+1 in system
> >>> physical address space.
> >>>
> >>> Therefore, code which has a buffer spanning a page boundary can't just
> >>> convert a pointer to the buffer into a physical address, and hand that
> >>> address to a device.  You generally end up with either memory corruption
> >>> (DMA hitting the wrong page allocated to the guest), or an IOMMU fault
> >>> (DMA hitting a pages which isn't allocated to the guest).
> >
> > The Linux DMA API allows for dma_map_page / dma_map_single calls to
> > spawn 4k boundaries.  If Xen doesn't support that it will have to bounce
> > buffer for that case (and get horrible performance).
> >
> > But the latter text seems to agree with that.  So what is the actual
> > problem that started this discussion?
> >
> See https://lists.xen.org/archives/html/xen-devel/2019-02/threads.html#00818

I believe the actual problem is either:

1) The radeon/amdgpu drivers are calling ttm_populate_and_map_pages()
which *should* work on a Xen PV host, but doesn't and needs to be


2) The radeon/amdgpu drivers are calling ttm_populate_and_map_pages()
which *cannot* work in Xen, and they should go back to calling
ttm_dma_populate() in that case.

I'm having a hard time figuring out which of those is correct.

Michael D Labriola
21 Rip Van Winkle Cir
Warwick, RI 02886
401-316-9844 (cell)
401-848-8871 (work)
401-234-1306 (home)

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.