Bug#404148: i'm not convinced release notes are enough
Hi.
Sorry that I've ignored the last answers to the bug but I somehow missed
the mail.
First of all,.. there is still no other solution than iommu=soft (at
least as of my knowledge) and we had even someone on the bugreport at
bugzilla.kernel.org who claimed that _only_ iommu=soft helped, but not
BIOS memhole mapping = disabled.
> AIUI the bug triggers on systems with memory in excess of 5GB. Limited to
> server-class hardware. I hope server admins are aware of the contents of
> release notes.
>
I don't think that you can rely on this. And even if so. Some could
probably just ignore it because their "small" tests don't show an
corruption and people might think they're on the safe side.
>> what is the performance impact of using the safe option on all hardware
>> even that not affected by this bug? would using that option by default
>> result in a noticable performance degrdation?
>>
> It's unknown to me whether all other currently-supported systems even *work*
> if iommu=soft is set.
As far as I know,.. everything should. For example Intel CPUs don't have
an IOMMU at all,... Windows uses always a kind of software iommu (even
on AMD CPUs).
> This is not the time to gamble with the kernel.
>
In all doing respect, I think that it's a much greater risk to not use
iommu=soft per default than doing so. Even if we imagine that there
would by systems that don't work with the sw-iommu.... it's likely that
they simply break (at boot time). And then the affected user at least
knows that something is happening to him, while with no iommu=soft he
would probably never realize that he has problems.
> If a targetted patch is available that sets iommu=soft for the chipset in
> question,
I think this will never happen. The problem is simply: Kernel developers
cannot tell which chipsets are affected, or which chipset/CPU combinations.
We even don't know yet where the error comes from (CPU or nvidia
chipset). According to Andi Kleen this is still being investiagted by
nvidia and AMD.
So such a patch would have to whitelist systems that are known to work,
instead of blacklist the others.
> that would be a good candidate for the next kernel upload, which
> may or may not make it into r0. But if no one has a good fix to offer, I
> think we need to settle for documenting it as errata given that upstream
> doesn't have a proper fix for this yet
Let me qoute Andi Kleen:
"Unless a good workaround comes around soon I'll probably default to
iommu=soft on Nvidia."
You see that even he thinks about using iommu=soft as default (on
nvidia). And until such a patch is available I think the saftest would
be to use it as a general default on amd64. Perhaps Debians kernel team
could even maintain their own patch that would activate iommu=soft only
on nvidia chipsets.
Best wishes,
Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:calestyo@scientia.net
x-mozilla-html:TRUE
version:2.1
end:vcard
Reply to: