Re: [PATCH] x86/tsx: Cope with RTM_ALWAYS_ABORT vs RTM mismatch

[Jan Beulich <jbeulich@suse.com>]

On 05.04.2024 15:01, Andrew Cooper wrote:
> On 04/04/2024 2:32 pm, Jan Beulich wrote:
>> On 04.04.2024 15:22, Andrew Cooper wrote:
>>> On 04/04/2024 1:45 pm, Jan Beulich wrote:
>>>>> +             * Spot this case, and treat it as if no TSX is available at all.
>>>>> +             * This will prevent Xen from thinking it's safe to offer HLE/RTM
>>>>> +             * to VMs.
>>>>> +             */
>>>>> +            if ( val == 0 && cpu_has_rtm_always_abort && !cpu_has_rtm )
>>>>> +            {
>>>>> +                printk(XENLOG_ERR
>>>>> +                       "FIRMWARE BUG: CPU %02x-%02x-%02x, ucode 0x%08x: RTM_ALWAYS_ABORT vs RTM mismatch\n",
>>>> This isn't really firmware, is it? At least I wouldn't call microcode
>>>> (assuming that's where the bad behavior is rooted) firmware.
>>> Microcode is absolutely part of the system firmware.
>> The ucode ahead of being loaded into CPUs is, sure. But once in the CPU
>> (and there may not be any loading at least in theory), it's not anymore.
> 
> You appear to have a very singular impression of what does and does not
> constitute firmware.

Not so singular, I would say: https://en.wikipedia.org/wiki/Firmware
The only mention of microcode there is for historical context, afaics.

Jan

> If you can change Intel and AMD's mind on this matter, feel free to
> submit a patch changing the wording here.
> 
> ~Andrew