All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: jan.kiszka@siemens.com, mtosatti@redhat.com,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [PATCH uq/master 2/2] kvm: forward INIT signals coming from the chipset
Date: Sun, 10 Mar 2013 16:04:39 +0100	[thread overview]
Message-ID: <513CA107.5030602@redhat.com> (raw)
In-Reply-To: <20130310145524.GJ24444@redhat.com>

Il 10/03/2013 15:55, Gleb Natapov ha scritto:
> > > Why not move INIT case from below as is? Vcpu is reset to correct sate
> > > by QEMU just like during system_reset.
> > 
> > APs would not be able to receive SIPIs after executing do_cpu_init,
> > because they would stay in KVM_MP_STATE_RUNNABLE state.
> 
> If APs are in runnable state after reset with in kernel irq chip we
> have a bug somewhere.

Here is where we are resetting the processor.  After clearing
CPU_INTERRUPT_INIT, no matter what else we do (such as resetting the
APIC and CPU), we need to set the mp_state to KVM_MP_STATE_INIT_RECEIVED.

Or if we go with your simpler hypervisor patch, we need to go to either
KVM_MP_STATE_INIT_RECEIVED for APs (wait for SIPI) or
KVM_MP_STATE_SIPI_RECEIVED for the BSP (restart running from the reset
vector).

> Should AP be able to get SIPI without INIT after trigger of INIT# line?

Yes, the effect is the same for an INIT interrupt and the triggering of
INIT#.

Paolo

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: jan.kiszka@siemens.com, mtosatti@redhat.com,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH uq/master 2/2] kvm: forward INIT signals coming from the chipset
Date: Sun, 10 Mar 2013 16:04:39 +0100	[thread overview]
Message-ID: <513CA107.5030602@redhat.com> (raw)
In-Reply-To: <20130310145524.GJ24444@redhat.com>

Il 10/03/2013 15:55, Gleb Natapov ha scritto:
> > > Why not move INIT case from below as is? Vcpu is reset to correct sate
> > > by QEMU just like during system_reset.
> > 
> > APs would not be able to receive SIPIs after executing do_cpu_init,
> > because they would stay in KVM_MP_STATE_RUNNABLE state.
> 
> If APs are in runnable state after reset with in kernel irq chip we
> have a bug somewhere.

Here is where we are resetting the processor.  After clearing
CPU_INTERRUPT_INIT, no matter what else we do (such as resetting the
APIC and CPU), we need to set the mp_state to KVM_MP_STATE_INIT_RECEIVED.

Or if we go with your simpler hypervisor patch, we need to go to either
KVM_MP_STATE_INIT_RECEIVED for APs (wait for SIPI) or
KVM_MP_STATE_SIPI_RECEIVED for the BSP (restart running from the reset
vector).

> Should AP be able to get SIPI without INIT after trigger of INIT# line?

Yes, the effect is the same for an INIT interrupt and the triggering of
INIT#.

Paolo

  reply	other threads:[~2013-03-10 15:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-09  6:48 [PATCH uq/master 0/2] CPU reset (INIT#) support for KVM Paolo Bonzini
2013-03-09  6:48 ` [Qemu-devel] " Paolo Bonzini
2013-03-09  6:48 ` [PATCH uq/master 1/2] kvm: detect errors from kvm_arch_process_async_events Paolo Bonzini
2013-03-09  6:48   ` [Qemu-devel] " Paolo Bonzini
2013-03-09  6:48 ` [PATCH uq/master 2/2] kvm: forward INIT signals coming from the chipset Paolo Bonzini
2013-03-09  6:48   ` [Qemu-devel] " Paolo Bonzini
2013-03-10 11:54   ` Gleb Natapov
2013-03-10 11:54     ` [Qemu-devel] " Gleb Natapov
2013-03-10 14:28     ` Paolo Bonzini
2013-03-10 14:28       ` [Qemu-devel] " Paolo Bonzini
2013-03-10 14:55       ` Gleb Natapov
2013-03-10 14:55         ` [Qemu-devel] " Gleb Natapov
2013-03-10 15:04         ` Paolo Bonzini [this message]
2013-03-10 15:04           ` Paolo Bonzini
2013-03-10 15:24           ` Gleb Natapov
2013-03-10 15:24             ` [Qemu-devel] " Gleb Natapov
2013-03-11  7:35             ` Paolo Bonzini
2013-03-11  7:35               ` [Qemu-devel] " 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=513CA107.5030602@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=gleb@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.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.