So far so good. Without any workaround, I could get it to fail within a few
seconds. With your change, I've been running for a few minutes without a
problem. But, this is on my laptop, so I'll wait until I can test it on a
wider-range of machines at work next week. If it continues to work, I'll
update my patch to include this fix.
Now, can you help me understand why this approach is better than what I had
written? When we're in hvf_store_events(), we have vector type and number.
All the information we need to reinject later. So why not save vector type
away, instead of attempting to reconstruct it from other information
(env->ins_len) in hvf_inject_interrupts()?
Cameron Esfahani
di...@apple.com
"There are times in the life of a nation when the only place a decent man can
find himself is in prison."
> On Nov 28, 2019, at 5:56 AM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
> On 26/11/19 21:04, Cameron Esfahani wrote:
>> Our test case was booting many concurrent macOS VMs under heavy
>> system load. I don't know if I could create one to replicate that.
>
> Does this work?
>
> diff --git a/target/i386/hvf/x86hvf.c b/target/i386/hvf/x86hvf.c
> index 1485b95776..26c6c3a49f 100644
> --- a/target/i386/hvf/x86hvf.c
> +++ b/target/i386/hvf/x86hvf.c
> @@ -357,7 +357,11 @@ bool hvf_inject_interrupts(CPUState *cpu_state)
> bool have_event = true;
> if (env->interrupt_injected != -1) {
> vector = env->interrupt_injected;
> - intr_type = VMCS_INTR_T_SWINTR;
> + if (env->ins_len) {
> + intr_type = VMCS_INTR_T_SWINTR;
> + } else {
> + intr_type = VMCS_INTR_T_HWINTR;
> + }
> } else if (env->exception_nr != -1) {
> vector = env->exception_nr;
> if (vector == EXCP03_INT3 || vector == EXCP04_INTO) {
>
> Thanks,
>
> Paolo
>
