Date: Mon, 29 Apr 2019 17:56:34 +0100 From: Johannes Lundberg <johalun@FreeBSD.org> To: Tycho Nightingale <tychon@freebsd.org> Cc: "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org> Subject: Re: dmar, dma_pool, etc Message-ID: <a819de4d-02d3-febf-6873-ce260085778f@FreeBSD.org> In-Reply-To: <9E2356CF-6483-4C06-B4A8-0120088063FE@freebsd.org> References: <e0415524-3126-5ea2-c2e2-3d3dccc6832e@FreeBSD.org> <9E2356CF-6483-4C06-B4A8-0120088063FE@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/29/19 3:41 PM, Tycho Nightingale wrote: > Hi, > >> On Apr 27, 2019, at 2:46 PM, Johannes Lundberg <johalun@FreeBSD.org> wrote: >> >> Hi >> >> Tycho, I'd like to understand what is the goal with the changes to >> linuxkpi and what you plan to use it for. LinuxKPI base is tightly >> connected to LinuxkPI GPLv2 and the DRM drivers in ports. We need to >> make sure that any change to base LinuxKPI is compatible with what we >> have in ports, or patch the ports to handle the changes in base. > Understood. The reports of the recent change to LinuxKPI having untoward effects are concerning. I’m trying to get more information to understand them and at the same time setup a machine in an attempt to reproduce them. > > Stepping back a bit, my addition of bus_dma to LinuxKPI is to make the mlx4/mlx5 drivers work in an environment where the IOMMU is enabled. Before physical addresses and dma addresses were not differentiated making this impossible. The intention of my patch was to get these devices into compliance and perhaps also other devices; minimally when the IOMMU is disabled things should behave as they were before. Got it! Thanks for the explanation. > >> For example, there is a CONFIG_INTEL_IOMMU options in Linux code that >> enables DMAR. It turns out, ttm has it's own dma_pool implementation. >> This is possible since in Linux dma_pool is private to dmapool.c. >> Enabling this option for us cause a compile error since dma_pool is >> public in base linuxkpi. I don't know if this is really a problem if >> CONFIG_INTEL_IOMMU (or CONFIG_SWIOTBL) are options that we'll never use… > Sounds like there is some redundancy there which can be eliminated. But with respect to your question of enabling the IOMMU outside of base; that’s more than what I intended to. Yes I understand. Can struct dma_pool be private in your implementation? I think it's better to follow Linux right away so we don't end up with collisions in the future when we decide to enable new features. > >> Also, we do have a problem with Firefox causing GPU hangs so I'd >> appreciate it if Tycho could look through linuxkpi_gplv2, drm and >> i915kms (i915kms does not use ttm so no need to look there for problems >> with Intel GPU) to see if there are any places needing patching. I know >> there's one vtophys() call in fb_mmap() but IIRC, that is never used. >> I'll look into that next. There are also uses of PHYS_TO_DMAP() and >> VM_PAGE_TO_PHYS(). Would any of these need patching? >> >> Use the default branch at https://github.com/FreeBSDDesktop/kms-drm > I’m planning to have a look, but to get things working as before nothing further should need patching even if the physical addresses are treated as dma addresses. > > For the GPU it’s important to note that enabling the IOMMU didn’t work before, was not a goal of this error, and would be expected to not work right now. However, it’s possible this change revealed some cases where some DMAR functionality was enabled in the BIOS and since the support is incomplete breakage is happening. Or something else that I am overlooking right now. Especially i915's GEM (i915_gem.c) have a lot of FreeBSD specific patches related to memory. Any FreeBSD code in drm drivers is within #ifndef __linux__ tags so it's easy locate our patches. It could also be some inconsistency between linuxkpi in base and linuxkpi gplv2 in ports. I don't think disabling options in BIOS in the correct solution. This would also disable functionality for virtual machines. > > > Tycho
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a819de4d-02d3-febf-6873-ce260085778f>