Re: [PATCH 5.18 01/11] Documentation: Add documentation for Processor MMIO Stale Data
From: Jonathan Corbet
Date: Wed Jun 15 2022 - 10:29:28 EST
Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx> writes:
> On Wed, Jun 15, 2022 at 08:06:37AM +0700, Bagas Sanjaya wrote:
>>On 6/15/22 01:40, Greg Kroah-Hartman wrote:
>>> + .. list-table::
>>> +
>>> + * - 'Not affected'
>>> + - The processor is not vulnerable
>>> + * - 'Vulnerable'
>>> + - The processor is vulnerable, but no mitigation enabled
>>> + * - 'Vulnerable: Clear CPU buffers attempted, no microcode'
>>> + - The processor is vulnerable, but microcode is not updated. The
>>> + mitigation is enabled on a best effort basis.
>>> + * - 'Mitigation: Clear CPU buffers'
>>> + - The processor is vulnerable and the CPU buffer clearing mitigation is
>>> + enabled.
>>> +
>>> +If the processor is vulnerable then the following information is appended to
>>> +the above information:
>>> +
>>> + ======================== ===========================================
>>> + 'SMT vulnerable' SMT is enabled
>>> + 'SMT disabled' SMT is disabled
>>> + 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown
>>> + ======================== ===========================================
>>> +
>>
>>Why is list-table used in sysfs table instead of usual ASCII table in SMT
>>vulnerabilities list above? I think using ASCII table in both cases is enough
>>for the purpose.
>
> Maybe you are right (and I am no expert in this), but quite a few
> documents use list-table for sysfs status:
>
> https://www.kernel.org/doc/Documentation/admin-guide/hw-vuln/mds.rst
> https://www.kernel.org/doc/Documentation/admin-guide/hw-vuln/spectre.rst
> https://www.kernel.org/doc/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
List-table should really be avoided whenever possible; it makes reading
the plain-text files difficult at best. I'd like to see the existing
uses taken out over time.
This isn't really something to be addressed in the stable updates,
though.
jon