> On Jun 19, 2020, at 6:50 AM, Richard Hughes <hughsi...@gmail.com> wrote: > > On Fri, 19 Jun 2020 at 14:44, Borislav Petkov <b...@alien8.de> wrote: >> Yes, this is what I'm proposing with clearing the flag in /proc/cpuinfo. >> The needed information is there: >> 1. TME in CPUID >> 2. TME *not* in /proc/cpuinfo > > No, it's not a boolean at all. If the platform disable is a BIOS > configuration we don't know if TME isn't available because the CPU > doesn't support it or because the firmware has disabled it. In the > latter case, a firmware update or firmware configuration change might > actually enable it. If the user installs a CPU with TME support and > then we tell the user "your system doesn't support TME" then we're > going to have some very confused users unless we can differentiate the > two cases. > >> Along with proper ABI definition, design, >> documentation and all that belongs to a proper interface with userspace. > > I don't think Daniels patch was a "final version" and I'm sure > follow-ups can add this kind of thing. At the moment it's just people > telling him "you don't need this" when as a potential consumer I'm > saying we really do.
I think it’s reasonable for the kernel to ask why. Is the idea that some GUI would show a big warning like “your silly BIOS has TME disabled”? Boris, it wouldn’t be totally crazy for cpuinfo to learn to distinguish between “your platform has this feature but Linux isn’t using it” and “your platform doesn’t have this feature in the first place”. And I suppose there’s this extra silly state “your platform has this feature, but your firmware didn’t enable it”. This would be a big job. Regardless, knowing what the actual point of this patch is would be nice. > > Richard.
