All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Cameron Esfahani <dirty@apple.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH v2 5/5] hvf: save away type as well as vector so we can reinject them
Date: Sat, 30 Nov 2019 09:46:47 +0100	[thread overview]
Message-ID: <ad54c701-7aef-362c-1580-416b9e41bc29@redhat.com> (raw)
In-Reply-To: <4EA34107-C294-47F4-8747-5407588BCA5C@apple.com>

On 30/11/19 09:31, Cameron Esfahani wrote:
> 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.

Great!  Note that there was a follow-up hunk in another email.

> 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()?

No huge reason, I agree.  However, the event injection code in the
Android emulator was broken for pretty much every corner case, so when
we rewrote it in QEMU for Summer of Code we took KVM as a model (commit
b7394c8394, "i386: hvf: refactor event injection code for hvf",
2017-12-22).  Keeping the code similar can help with debugging, so I
prefer having the same meaning for env->interrupt_injected and
env->exception_nr across HVF and KVM.

I didn't write the code for KVM, so I cannot really say why they chose
to not save the event type.

Thanks,

Paolo

> 
> Cameron Esfahani
> dirty@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 <pbonzini@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
>>
> 



  reply	other threads:[~2019-11-30  8:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-24 20:05 [PATCH v2 0/5] hvf: stability fixes for HVF Cameron Esfahani via
2019-11-24 20:05 ` [PATCH v2 1/5] hvf: non-RAM, non-ROMD memory ranges are now correctly mapped in Cameron Esfahani via
2019-11-24 20:05 ` [PATCH v2 2/5] hvf: remove TSC synchronization code because it isn't fully complete Cameron Esfahani via
2019-11-24 20:05 ` [PATCH v2 3/5] hvf: correctly handle REX prefix in relation to legacy prefixes Cameron Esfahani via
2019-11-24 20:05 ` [PATCH v2 4/5] hvf: more accurately match SDM when setting CR0 and PDPTE registers Cameron Esfahani via
2019-11-24 20:05 ` [PATCH v2 5/5] hvf: save away type as well as vector so we can reinject them Cameron Esfahani via
2019-11-25 10:26   ` Paolo Bonzini
2019-11-26 20:04     ` Cameron Esfahani via
2019-11-28  5:57       ` Cameron Esfahani via
2019-11-28 13:52         ` Paolo Bonzini
2019-11-28 13:56       ` Paolo Bonzini
2019-11-28 13:59         ` Paolo Bonzini
2019-11-30  8:31         ` Cameron Esfahani via
2019-11-30  8:46           ` Paolo Bonzini [this message]
2019-11-25 10:28 ` [PATCH v2 0/5] hvf: stability fixes for HVF Paolo Bonzini
2019-11-26 20:10   ` Cameron Esfahani via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad54c701-7aef-362c-1580-416b9e41bc29@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=dirty@apple.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.