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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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?

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel