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

[Michael Labriola <michael.d.labriola@xxxxxxxxx>]

On Wed, Feb 13, 2019 at 3:21 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 13/02/2019 20:15, Michael Labriola wrote:
> > On Wed, Feb 13, 2019 at 2:16 PM Konrad Rzeszutek Wilk
> > <konrad.wilk@xxxxxxxxxx> wrote:
> >> On Wed, Feb 13, 2019 at 01:38:21PM -0500, Michael Labriola wrote:
> >>> On Wed, Feb 13, 2019 at 1:16 PM Michael Labriola
> >>> <michael.d.labriola@xxxxxxxxx> wrote:
> >>>> On Wed, Feb 13, 2019 at 11:57 AM Konrad Rzeszutek Wilk
> >>>> <konrad.wilk@xxxxxxxxxx> wrote:
> >>>>> On Wed, Feb 13, 2019 at 09:09:32AM -0700, Jan Beulich wrote:
> >>>>>>>>> On 13.02.19 at 17:00, <michael.d.labriola@xxxxxxxxx> wrote:
> >>>>>>> On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>>>>>>>>>> On 13.02.19 at 15:10, <michael.d.labriola@xxxxxxxxx> wrote:
> >>>>>>>>> Ah, so this isn't necessarily Xen-specific but rather any 
> >>>>>>>>> paravirtual
> >>>>>>>>> guest?  That hadn't crossed my mind.  Is there an easy way to find 
> >>>>>>>>> out
> >>>>>>>>> if we're a pv guest in the need_swiotlb conditionals?
> >>>>>>>> There's xen_pv_domain(), but I think xen_swiotlb would be more to
> >>>>>>>> the point if the check is already to be Xen-specific. There's no 
> >>>>>>>> generic
> >>>>>>>> "is PV" predicate that I'm aware of.
> >>>>>>> Well, that makes doing conditional code right more difficult.  I
> >>>>>>> assume since there isn't a generic predicate, and PV isn't new, that
> >>>>>>> it's absence is by design?  To reign in the temptation to sprinkle
> >>>>>>> conditional code all over the kernel?  ;-)
> >>>>>> Well, with lguest gone, Xen is the only PV environment the kernel
> >>>>>> can run in, afaik at least. I guess to decide between the suggested
> >>>>>> options or the need for some abstracting macro (or yet something
> >>>>>> else), you'll really need to ask the driver maintainers. Or simply
> >>>>>> send a patch their way implementing one of them, and see what
> >>>>>> their reaction is.
> >>>>> Could you try this out and see if it works and I will send it out:
> >>>>>
> >>> *snip*
> >>>> Yes, that works for me.  However, I feel like the conditional should
> >>>> be in drm_get_max_iomem() instead of directly after it everywhere it's
> >>>> used...  and is just checking xen_pv_domain() enough?  Jan made it
> >>>> sound like there were possibly other PV cases that would also still
> >>>> need swiotlb.
> >>> How about this?  It strcmp's pv_info to see if we're bare metal, does
> >>> the comparison in a single place, moves the bit shifting comparison
> >>> into the function (simplifying the drm driver code), and renames the
> >>> function to more aptly describe what's going on.
> >> <nods> That looks much better.
> > Great!  Now the only question left is:  KVM, VMware, Xen PVH, Xen HVM,
> > and Xen PV all populate pv_info.  Do any of those other than Xen PV
> > *really* need swiotlb.  That's slightly over my head.  As written, my
> > patch would require swiotlb for all of them because I was attempting
> > to not be Xen-specific.
>
> Its far more complicated that "Xen PV requires swiotlb".
>
> I presume the underlying problem here is DRM being special and not
> DMA-mapping its buffers, and trying to DMA to a buffer crossing a 4k
> boundary?

Well, I don't 100% understand how all these things work...  but here's
what I do know.  There are a series of commits in v4.17 that try to
optimize the radeon and amdgpu drivers by skipping calls to
ttm_dma_populate() and ttm_dma_unpopulate() unless they're "really
needed".  The original commit determines if swiotlb is needed by
checking to see if the max io mapping address of system memory is over
the video card's accessing range.  I can no longer log into Gnome on a
Xen dom0 after upgrading my kernel to v4.20 because the code that's no
longer happening was actually needed in a paravirtualized environment.

So, I'm trying to get all my details straight so I can submit a patch
to fix it w/out saying anything factually incorrect.

> Buffers sitting entirely within one 4k frame never need the swiotlb
> unless you've only got a 32-bit capable graphics card, and there is
> separate mode dma-mapping mode in the process of being upstreamed where
> frames which most of Linux things are adjacent do appear adjacent in
> device-virtual address space.
>
> ~Andrew

-- 
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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel