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

[Elliot Killick <elliotkillick@xxxxxxxxxxx>]

On 2020-05-20 12:31, Andrew Cooper wrote:
> On 20/05/2020 12:46, Elliot Killick wrote:
>> On 2020-05-20 11:27, Andrew Cooper wrote:
>>> On 20/05/2020 12:20, Elliot Killick wrote:
>>>> On 2020-05-20 11:10, Andrew Cooper wrote:
>>>>> On 20/05/2020 11:33, Elliot Killick wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Xen is crashing Windows 10 (64-bit) VMs consistently whenever IDA
>>>>>> Debugger
>>>>>> (https://www.hex-rays.com/products/ida/support/download_freeware/)
>>>>>> launches the Local Windows Debugger. The crash occurs when trying to
>>>>>> launch the debugger against any executable (e.g. calc.exe) right at the
>>>>>> time IDA says it is "Moving segment from <X address> to <Y address>".
>>>>>>
>>>>>> Tested on Windows 7, 8 and Linux as well but the bug is only triggered
>>>>>> on Windows 10. Happens whether or not IDA is running with administrator
>>>>>> privileges. No drivers/VM tools installed. Windows has a bug check code
>>>>>> of zero, leaves no memory dump, nothing in the logs from QEMU in Dom0,
>>>>>> the domain just powers off immediately leaving a record of the incident
>>>>>> in the hypervisor.log. So, it does appear to be a Xen issue. Modern
>>>>>> Intel CPU.
>>>>>>
>>>>>> Does anyone have some ideas on what may be causing this?
>>>>> What exact CPU do you have?  This looks exactly like the
>>>>> Haswell/Broadwell TSX errata.
>>>>>
>>>>> ~Andrew
>>>>>
>>>> i5-4590
>>> How about the output of `head /proc/cpuinfo` in dom0?
>>>
>>> ~Andrew
>>>
>> 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.

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.

Thank you for the help, Andrew!