From: Gleb Natapov <gleb@redhat.com>
To: Paolo Bonzini <pbonzini@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 17:24:06 +0200 [thread overview]
Message-ID: <20130310152406.GK24444@redhat.com> (raw)
In-Reply-To: <513CA107.5030602@redhat.com>
On Sun, Mar 10, 2013 at 04:04:39PM +0100, Paolo Bonzini wrote:
> 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).
>
No need for KVM_MP_STATE_SIPI_RECEIVED. Just make it RUNNING. This is similar to
system_reset path, not? UNINIT for AP, RUNNING for BSP.
> > 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#.
>
Can you give me SDM pointer?
--
Gleb.
WARNING: multiple messages have this Message-ID (diff)
From: Gleb Natapov <gleb@redhat.com>
To: Paolo Bonzini <pbonzini@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 17:24:06 +0200 [thread overview]
Message-ID: <20130310152406.GK24444@redhat.com> (raw)
In-Reply-To: <513CA107.5030602@redhat.com>
On Sun, Mar 10, 2013 at 04:04:39PM +0100, Paolo Bonzini wrote:
> 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).
>
No need for KVM_MP_STATE_SIPI_RECEIVED. Just make it RUNNING. This is similar to
system_reset path, not? UNINIT for AP, RUNNING for BSP.
> > 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#.
>
Can you give me SDM pointer?
--
Gleb.
next prev parent reply other threads:[~2013-03-10 15:24 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
2013-03-10 15:04 ` [Qemu-devel] " Paolo Bonzini
2013-03-10 15:24 ` Gleb Natapov [this message]
2013-03-10 15:24 ` 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=20130310152406.GK24444@redhat.com \
--to=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pbonzini@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.