On 28/11/19 06:57, Cameron Esfahani wrote:
>
> What we were seeing was, under heavy loads, running many concurrent
macOS VMs, that we would get spurious interrupts. Tracking it down, we
discovered that VMCS_INTR_T_SWINTR was getting injected when
VMCS_INTR_T_HWINTR was expected.
>
> If I take our proposed patch code, which built on top of master from a
> few days ago, and has fd13f23b8c95311eff74426921557eee592b0ed3, and add
> an assert, like the following:
>
>> if (env->interrupt_injected != -1) {
>> /* Type and vector are both saved in interrupt_injected. */
>> vector = env->interrupt_injected & VMCS_IDT_VEC_VECNUM;
>> intr_type = env->interrupt_injected & VMCS_IDT_VEC_TYPE;
>> if (VMCS_INTR_T_SWINTR != intr_type) {
>> printf("VMCS_INTR_T_SWINTR (%x) != intr_type (%llx)\n",
>> VMCS_INTR_T_SWINTR, intr_type);
>> assert(VMCS_INTR_T_SWINTR == intr_type);
>> }
>> } else if (env->exception_nr != -1) {
>
> Then we will see the assert trigger and get the following output:
>
>> VMCS_INTR_T_SWINTR (400) != intr_type (0)
>> Assertion failed: (VMCS_INTR_T_SWINTR == intr_type), function
>> hvf_inject_interrupts, file qemu_upstream/target/i386/hvf/x86hvf.c, line 362.
Great, thanks. It's good to know that it's only software vs. hardware
interrupt. I'll compare the KVM and QEMU source code to see why KVM
does not lose software vs. hardware interrupt, since the QEMU event
injection code was modeled against KVM's.
Paolo
