All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>,
	kvm <kvm@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [PATCH] kvm: First step to push iothread lock out of inner run loop
Date: Sat, 23 Jun 2012 06:06:46 -0300	[thread overview]
Message-ID: <20120623090646.GA21908@amt.cnet> (raw)
In-Reply-To: <20120623002259.GA13440@amt.cnet>

On Fri, Jun 22, 2012 at 09:22:59PM -0300, Marcelo Tosatti wrote:
> On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
> > Should have declared this [RFC] in the subject and CC'ed kvm...
> > 
> > On 2012-06-23 00:45, Jan Kiszka wrote:
> > > This sketches a possible path to get rid of the iothread lock on vmexits
> > > in KVM mode. On x86, the the in-kernel irqchips has to be used because
> > > we otherwise need to synchronize APIC and other per-cpu state accesses
> > > that could be changed concurrently. Not yet fully analyzed is the NMI
> > > injection path in the absence of an APIC.
> > > 
> > > s390x should be fine without specific locking as their pre/post-run
> > > callbacks are empty. Power requires locking for the pre-run callback.
> > > 
> > > This patch is untested, but a similar version was successfully used in
> > > a x86 setup with a network I/O path that needed no central iothread
> > > locking anymore (required special MMIO exit handling).
> > > ---
> > >  kvm-all.c         |   18 ++++++++++++++++--
> > >  target-i386/kvm.c |    7 +++++++
> > >  target-ppc/kvm.c  |    4 ++++
> > >  3 files changed, 27 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/kvm-all.c b/kvm-all.c
> > > index f8e4328..9c3e26f 100644
> > > --- a/kvm-all.c
> > > +++ b/kvm-all.c
> > > @@ -1460,6 +1460,8 @@ int kvm_cpu_exec(CPUArchState *env)
> > >          return EXCP_HLT;
> > >      }
> > >  
> > > +    qemu_mutex_unlock_iothread();
> > > +
> > >      do {
> > >          if (env->kvm_vcpu_dirty) {
> > >              kvm_arch_put_registers(env, KVM_PUT_RUNTIME_STATE);
> > > @@ -1476,14 +1478,16 @@ int kvm_cpu_exec(CPUArchState *env)
> > >               */
> > >              qemu_cpu_kick_self();
> > >          }
> > > -        qemu_mutex_unlock_iothread();
> > >  
> > >          run_ret = kvm_vcpu_ioctl(env, KVM_RUN, 0);
> > >  
> > > -        qemu_mutex_lock_iothread();
> > >          kvm_arch_post_run(env, run);
> 
> target-i386/kvm.c
> 
> void kvm_arch_post_run(CPUX86State *env, struct kvm_run *run)
> {       
>     if (run->if_flag) {
>         env->eflags |= IF_MASK;
>     } else {
>         env->eflags &= ~IF_MASK;
>     }
>     cpu_set_apic_tpr(env->apic_state, run->cr8);
>     cpu_set_apic_base(env->apic_state, run->apic_base);
> }
> 
> Clearly there is no structure to any of the writes around the writes
> in x86's kvm_arch_post_run, so it is unsafe.

No access protocol to the CPUState and apic devices (who can write when,
who can read when).

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>,
	kvm <kvm@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop
Date: Sat, 23 Jun 2012 06:06:46 -0300	[thread overview]
Message-ID: <20120623090646.GA21908@amt.cnet> (raw)
In-Reply-To: <20120623002259.GA13440@amt.cnet>

On Fri, Jun 22, 2012 at 09:22:59PM -0300, Marcelo Tosatti wrote:
> On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
> > Should have declared this [RFC] in the subject and CC'ed kvm...
> > 
> > On 2012-06-23 00:45, Jan Kiszka wrote:
> > > This sketches a possible path to get rid of the iothread lock on vmexits
> > > in KVM mode. On x86, the the in-kernel irqchips has to be used because
> > > we otherwise need to synchronize APIC and other per-cpu state accesses
> > > that could be changed concurrently. Not yet fully analyzed is the NMI
> > > injection path in the absence of an APIC.
> > > 
> > > s390x should be fine without specific locking as their pre/post-run
> > > callbacks are empty. Power requires locking for the pre-run callback.
> > > 
> > > This patch is untested, but a similar version was successfully used in
> > > a x86 setup with a network I/O path that needed no central iothread
> > > locking anymore (required special MMIO exit handling).
> > > ---
> > >  kvm-all.c         |   18 ++++++++++++++++--
> > >  target-i386/kvm.c |    7 +++++++
> > >  target-ppc/kvm.c  |    4 ++++
> > >  3 files changed, 27 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/kvm-all.c b/kvm-all.c
> > > index f8e4328..9c3e26f 100644
> > > --- a/kvm-all.c
> > > +++ b/kvm-all.c
> > > @@ -1460,6 +1460,8 @@ int kvm_cpu_exec(CPUArchState *env)
> > >          return EXCP_HLT;
> > >      }
> > >  
> > > +    qemu_mutex_unlock_iothread();
> > > +
> > >      do {
> > >          if (env->kvm_vcpu_dirty) {
> > >              kvm_arch_put_registers(env, KVM_PUT_RUNTIME_STATE);
> > > @@ -1476,14 +1478,16 @@ int kvm_cpu_exec(CPUArchState *env)
> > >               */
> > >              qemu_cpu_kick_self();
> > >          }
> > > -        qemu_mutex_unlock_iothread();
> > >  
> > >          run_ret = kvm_vcpu_ioctl(env, KVM_RUN, 0);
> > >  
> > > -        qemu_mutex_lock_iothread();
> > >          kvm_arch_post_run(env, run);
> 
> target-i386/kvm.c
> 
> void kvm_arch_post_run(CPUX86State *env, struct kvm_run *run)
> {       
>     if (run->if_flag) {
>         env->eflags |= IF_MASK;
>     } else {
>         env->eflags &= ~IF_MASK;
>     }
>     cpu_set_apic_tpr(env->apic_state, run->cr8);
>     cpu_set_apic_base(env->apic_state, run->apic_base);
> }
> 
> Clearly there is no structure to any of the writes around the writes
> in x86's kvm_arch_post_run, so it is unsafe.

No access protocol to the CPUState and apic devices (who can write when,
who can read when).

  reply	other threads:[~2012-06-23  9:06 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-22 22:45 [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop Jan Kiszka
2012-06-22 22:55 ` Jan Kiszka
2012-06-22 22:55   ` [Qemu-devel] " Jan Kiszka
2012-06-23  0:22   ` Marcelo Tosatti
2012-06-23  0:22     ` [Qemu-devel] " Marcelo Tosatti
2012-06-23  9:06     ` Marcelo Tosatti [this message]
2012-06-23  9:06       ` Marcelo Tosatti
2012-06-23 11:45       ` Jan Kiszka
2012-06-23 11:45         ` [Qemu-devel] " Jan Kiszka
2012-06-24  8:49         ` Avi Kivity
2012-06-24  8:49           ` [Qemu-devel] " Avi Kivity
2012-06-24 14:08           ` Jan Kiszka
2012-06-24 14:08             ` Jan Kiszka
2012-06-24 14:31             ` Avi Kivity
2012-06-24 14:31               ` Avi Kivity
2012-07-06 17:16             ` Jan Kiszka
2012-07-06 17:16               ` [Qemu-devel] " Jan Kiszka
2012-07-06 18:06               ` Jan Kiszka
2012-07-06 18:06                 ` [Qemu-devel] " Jan Kiszka
2012-07-08  7:49                 ` Avi Kivity
2012-07-08  7:49                   ` [Qemu-devel] " Avi Kivity
2012-06-24 13:34         ` liu ping fan
2012-06-24 13:34           ` [Qemu-devel] " liu ping fan
2012-06-24 14:08           ` Jan Kiszka
2012-06-24 14:08             ` [Qemu-devel] " Jan Kiszka
2012-06-24 14:35             ` Avi Kivity
2012-06-24 14:35               ` [Qemu-devel] " Avi Kivity
2012-06-24 14:40               ` Jan Kiszka
2012-06-24 14:40                 ` [Qemu-devel] " Jan Kiszka
2012-06-24 14:46                 ` Avi Kivity
2012-06-24 14:46                   ` [Qemu-devel] " Avi Kivity
2012-06-24 14:51                   ` Jan Kiszka
2012-06-24 14:51                     ` [Qemu-devel] " Jan Kiszka
2012-06-24 14:56                     ` Avi Kivity
2012-06-24 14:56                       ` [Qemu-devel] " Avi Kivity
2012-06-24 14:58                       ` Jan Kiszka
2012-06-24 14:58                         ` [Qemu-devel] " Jan Kiszka
2012-06-24 14:59                         ` Avi Kivity
2012-06-24 14:59                           ` [Qemu-devel] " Avi Kivity
2012-06-23  9:22     ` Jan Kiszka
2012-06-23  9:22       ` [Qemu-devel] " Jan Kiszka
2012-06-28  1:11       ` Marcelo Tosatti
2012-06-26 19:34   ` Marcelo Tosatti
2012-06-27  7:39     ` Stefan Hajnoczi
2012-06-27  7:41       ` [Qemu-devel] " Stefan Hajnoczi
2012-06-27 11:09         ` Marcelo Tosatti
2012-06-27 11:19         ` [Qemu-devel] " Marcelo Tosatti
2012-06-28  8:45           ` Stefan Hajnoczi
2012-06-27  7:54     ` Avi Kivity
2012-06-27 14:36     ` Jan Kiszka
2012-06-28 14:10     ` [Qemu-devel] " Anthony Liguori
2012-06-28 15:12       ` Avi Kivity
2012-06-29  1:29       ` Marcelo Tosatti
2012-06-29  1:45       ` [Qemu-devel] " Marcelo Tosatti
2012-06-22 22:59 ` Anthony Liguori
2012-06-23  9:11   ` Jan Kiszka

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=20120623090646.GA21908@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=agraf@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=pingfank@linux.vnet.ibm.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.