All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Bolshakov <r.bolshakov@yadro.com>
To: Claudio Fontana <cfontana@suse.de>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel@nongnu.org, Cameron Esfahani <dirty@apple.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH 4/8] i386: hvf: Implement CPU kick
Date: Thu, 25 Jun 2020 13:51:33 +0300	[thread overview]
Message-ID: <20200625105133.GF25104@SPB-NB-133.local> (raw)
In-Reply-To: <77df3139-501d-d4b9-c651-35de66474d57@suse.de>

On Thu, Jun 25, 2020 at 09:07:04AM +0200, Claudio Fontana wrote:
> Hi Roman,
> 
> On 6/25/20 12:58 AM, Roman Bolshakov wrote:
> > HVF doesn't have a CPU kick and without it it's not possible to perform
> > an action on CPU thread until a VMEXIT happens. The kick is also needed
> > for timely interrupt delivery.
> > 
> > Existing implementation of CPU kick sends SIG_IPI (aka SIGUSR1) to vCPU
> > thread, but it's different from what hv_vcpu_interrupt does. The latter
> > one results in invocation of mp_cpus_kick() in XNU kernel [1].
> > 
> > While at it, correct type of hvf_fd to the type of hv_vcpuid_t to avoid
> > compilation warnings.
> > 
> > 1. https://opensource.apple.com/source/xnu/xnu-6153.81.5/osfmk/i386/mp.c
> > 
> > Cc: Cameron Esfahani <dirty@apple.com>
> > Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
> > ---
> >  cpus.c                | 13 +++++++++----
> >  include/hw/core/cpu.h |  2 +-
> >  include/sysemu/hvf.h  |  1 +
> >  target/i386/hvf/hvf.c | 11 +++++++++++
> >  4 files changed, 22 insertions(+), 5 deletions(-)
> > 
> > diff --git a/cpus.c b/cpus.c
> > index 26709677d3..36f38ce5c8 100644
> > --- a/cpus.c
> > +++ b/cpus.c
> > @@ -1783,10 +1783,15 @@ static void qemu_cpu_kick_thread(CPUState *cpu)
> >          return;
> >      }
> >      cpu->thread_kicked = true;
> > -    err = pthread_kill(cpu->thread->thread, SIG_IPI);
> > -    if (err && err != ESRCH) {
> > -        fprintf(stderr, "qemu:%s: %s", __func__, strerror(err));
> > -        exit(1);
> > +
> > +    if (hvf_enabled()) {
> > +        hvf_vcpu_kick(cpu);
> 
> could this be moved to qemu_cpu_kick, where we have already the ifs for accelerator types tcg and hax?
> 

Hi Claudio,

I did this because of cpu->thread_kicked which is not set or tested in
qemu_cpu_kick(). It's not used for tcg and mttcg but hax does seem to
use the qemu_cpu_kick_thread() and additionally sets cpu->exit_request
in qemu_cpu_kick(). There's a difference between hax/kvm and hvf, they
use different ways of siginalling the kick. hax/kvm use POSIX signals
while HVF sends an IPI from the host LAPIC to deliver the kick. The
patch highlights the difference.

As far as I understand if thread_kicked is set, multiple cpu kicks are
coalesced until thread_kicked is cleared. So, the answer to your
question: It could be moved to qemu_cpu_kick but then kick debouncing
should be duplicated inside hvf_vcpu_kick().

Regards,
Roman

> Not terribly important if then my cpus-refactoring goes forward, but on its own that should be the proper place for if (hvf_enabled()) I think.
> 
> 
> 
> > +    } else {
> > +        err = pthread_kill(cpu->thread->thread, SIG_IPI);
> > +        if (err && err != ESRCH) {
> > +            fprintf(stderr, "qemu:%s: %s", __func__, strerror(err));
> > +            exit(1);
> > +        }
> >      }
> >  #else /* _WIN32 */
> >      if (!qemu_cpu_is_self(cpu)) {


  reply	other threads:[~2020-06-25 10:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 22:58 [PATCH 0/8] Improve synchronization between QEMU and HVF Roman Bolshakov
2020-06-24 22:58 ` [PATCH 1/8] i386: hvf: Set env->eip in macvm_set_rip() Roman Bolshakov
2020-06-24 22:58 ` [PATCH 2/8] i386: hvf: Move synchronize functions to sysemu Roman Bolshakov
2020-06-25  7:09   ` Claudio Fontana
2020-06-24 22:58 ` [PATCH 3/8] i386: hvf: Add hvf_cpu_synchronize_pre_loadvm() Roman Bolshakov
2020-06-24 22:58 ` [PATCH 4/8] i386: hvf: Implement CPU kick Roman Bolshakov
2020-06-25  7:07   ` Claudio Fontana
2020-06-25 10:51     ` Roman Bolshakov [this message]
2020-06-25 10:28   ` Paolo Bonzini
2020-06-25 15:57     ` Roman Bolshakov
2020-06-25 18:34       ` Paolo Bonzini
2020-06-29 11:31         ` Roman Bolshakov
2020-06-29 13:03           ` Paolo Bonzini
2020-06-29 13:29             ` Roman Bolshakov
2020-06-29 13:35               ` Paolo Bonzini
2020-06-29 14:04                 ` Roman Bolshakov
2020-06-29 14:18                   ` Paolo Bonzini
2020-06-30 10:12                     ` Roman Bolshakov
2020-06-30 10:43                       ` Paolo Bonzini
2020-06-24 22:58 ` [PATCH 5/8] i386: hvf: Don't duplicate register reset Roman Bolshakov
2020-06-24 22:58 ` [PATCH 6/8] i386: hvf: Drop hvf_reset_vcpu() Roman Bolshakov
2020-06-25 10:31   ` Paolo Bonzini
2020-06-25 12:36     ` Roman Bolshakov
2020-06-25 13:30       ` Paolo Bonzini
2020-06-25 15:02         ` Roman Bolshakov
2020-06-25 18:26           ` Paolo Bonzini
2020-06-29 12:58         ` Roman Bolshakov
2020-06-24 22:58 ` [PATCH 7/8] i386: hvf: Clean up synchronize functions Roman Bolshakov
2020-06-24 22:58 ` [PATCH 8/8] MAINTAINERS: Add Cameron as HVF co-maintainer Roman Bolshakov
2020-06-25 11:08 ` [PATCH 0/8] Improve synchronization between QEMU and HVF Paolo Bonzini

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=20200625105133.GF25104@SPB-NB-133.local \
    --to=r.bolshakov@yadro.com \
    --cc=cfontana@suse.de \
    --cc=dirty@apple.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.