On 08/03/2021 13:08, Robin Murphy wrote:
On 2021-03-05 17:41, John Garry wrote:
On 05/03/2021 16:32, Robin Murphy wrote:
In converting intel-iommu over to the common IOMMU DMA ops, it quietly
lost the functionality of its "forcedac" option. Since this is a handy
thing both for testing and for performance optimisation on certain
platforms, reimplement it under the common IOMMU parameter namespace.
For the sake of fixing the inadvertent breakage of the Intel-specific
parameter, remove the dmar_forcedac remnants and hook it up as an alias
while documenting the transition to the new common parameter.
Do you think that having a kconfig option to control the default for
this can help identify the broken platforms which rely on forcedac=0?
But seems a bit trivial for that, though.
I think it's still a sizeable can of worms - unlike, say,
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, we can't actually tell when things
have gone awry and explicitly call it out. While I was getting the
dma-ranges right on my Juno, everything broke differently - the SATA
controller fails gracefully; the ethernet controller got the kernel tied
up somewhere (to the point that the USB keyboard died) once it tried to
brink up the link, but was at least spewing regular timeout backtraces
that implicated the networking layer; having an (unused) NVMe plugged in
simply wedged the boot process early on with no hint whatsoever of why.
TBH I'm not really sure what the best way forward is in terms of trying
to weed out platforms that would need quirking.
I was more thinking of an unstable TEST config, like
DEBUG_TEST_DRIVER_REMOVE. So we know that this particular config breaks
many platforms. But at least those in the know can turn it on locally
and detect and fix issues, and strive towards having a platform for
which it works.
But then it does become a little harder to justify such a config when we
can enable via commadline.
Our discussion just
reminded me of this option and that it had gone AWOL, so bringing it
back to be potentially *some* use to everyone seems justifiable on its own.
Of course.
Cheers,
John
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
