Re: [BUG] Consistent LBR/TSX vmentry failure (0x80000022) calling domain_crash() in vmx.c:3324

[Elliot Killick <elliotkillick@xxxxxxxxxxx>]

On 2020-05-20 16:53, Andrew Cooper wrote:
> On 20/05/2020 15:59, Elliot Killick wrote:
>> On 2020-05-20 12:31, Andrew Cooper wrote:
>>> On 20/05/2020 12:46, Elliot Killick wrote:
>>>> processor  : 0
>>>> vendor_id  : GenuineIntel
>>>> cpu family : 6
>>>> model              : 60
>>>> model name : Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz
>>>> stepping   : 3
>>>> microcode  : 0x27
>>>> cpu MHz            : 3299.926
>>>> cache size : 6144 KB
>>>> physical id        : 0
>>> Ok, so the errata is one of HSM182/HSD172.
>>>
>>> Xen has workaround for all of these.  However, I also see:
>>>
>>>> (XEN) ----[ Xen-4.8.5-15.fc25  x86_64  debug=n   Not tainted ]----
>>> which is an obsolete version of Xen these days.  It looks like these
>>> issues were first fixed in Xen 4.9, but you should upgrade to something
>>> rather newer.
>>>
>>> ~Andrew
>>>
>> Ah, so this is originally a CPU bug which Xen has had to patch over.
> 
> Yes.  It was an unintended consequence of Intel being forced to disable
> TSX in most of their Haswell/Broadwell CPUs.
> 
>> As for the Xen version, that's controlled by the "distribution" of Xen I
>> run which is Qubes. To remedy this I could run the testing stream of
>> Qubes which currently provides the latest version of Xen (4.13) but that
>> could bring its own set of problems.
> 
> Ah, in which case Qubes will probably consider backporting the fixes. 
> Open a bug with them, and I can probably point out a minimum set of
> backports to make it work.
> 
> ~Andrew
> 

Hi, Andrew

I've opened up a bug with Qubes here:
https://github.com/QubesOS/qubes-issues/issues/5848

Please highlight the required backports at your earliest convenience,
thank you.