On 13/02/2019 20:15, Michael Labriola wrote: > On Wed, Feb 13, 2019 at 2:16 PM Konrad Rzeszutek Wilk > <konrad.w...@oracle.com> 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.labri...@gmail.com> wrote: >>>> On Wed, Feb 13, 2019 at 11:57 AM Konrad Rzeszutek Wilk >>>> <konrad.w...@oracle.com> wrote: >>>>> On Wed, Feb 13, 2019 at 09:09:32AM -0700, Jan Beulich wrote: >>>>>>>>> On 13.02.19 at 17:00, <michael.d.labri...@gmail.com> wrote: >>>>>>> On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich <jbeul...@suse.com> wrote: >>>>>>>>>>> On 13.02.19 at 15:10, <michael.d.labri...@gmail.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
