On Wed, 4 Dec 2019 at 20:56, Matthew Garrett <mjg59@xxxxxxxxxx> wrote: > > On Wed, Dec 4, 2019 at 11:50 AM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > > Wouldn't it also be applicable in the much simpler case where the > > firmware hands over control with no IOMMU configured but also with the > > busmastering bit cleared. Does firmware do this? Does the kernel > > currently configure the iOMMU before enabling busmastering? > > We already handle this case - the kernel doesn't activate busmastering > until after it does IOMMU setup. Build issues aside (which we already handled off list), I think we should consider the following concerns I have about this patch: - make it work on ARM (already done) - make the cmdline option an efi=xxx one, this makes it obvious which context this is active in - I would prefer it if we could make it more obvious that this affects PCI DMA only, other masters are unaffected by any of this. - I don't think the presence of the IOMMU is entirely relevant - even in the absence of an IOMMU, I would prefer bus mastering to be disabled until the OS driver takes control. This is already part of the EFI<->handover contract, but it makes sense to have this on top just in case. - What about integrated masters? On the systems I have access to, there are a lot of DMA capable endpoints that sit on bus 0 without any root port or PCI bridge in between - Should we treat GOP producers differently? Or perhaps only if the efifb address is known to be carved out of system memory? If we come up with a good story here in terms of policy, we may be able to enable this by default, which would be a win imo.
