From: Jan Kiszka <jan.kiszka@web.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Gleb Natapov <gleb@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH v2] KVM: x86: Convert INIT and SIPI signals into synchronously handled requests
Date: Wed, 06 Mar 2013 08:57:54 +0100 [thread overview]
Message-ID: <5136F702.4070101@web.de> (raw)
In-Reply-To: <70318159.3047162.1362550372481.JavaMail.root@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]
On 2013-03-06 07:12, Paolo Bonzini wrote:
>
>> On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
>>> On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> A VCPU sending INIT or SIPI to some other VCPU races for setting
>>>> the
>>>> remote VCPU's mp_state. When we were unlucky,
>>>> KVM_MP_STATE_INIT_RECEIVED
>>>> was overwritten by kvm_emulate_halt and, thus, got lost.
>>>>
>>>> Fix this by raising requests on the sender side that will then be
>>>> handled synchronously over the target VCPU context.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> Why is kvm_emulate_halt being executed from
>>> KVM_MP_STATE_INIT_RECEIVED/KVM_MP_STATE_SIPI_RECEIVED again?
>>>
>>> Why is it not true that the only valid transition from
>>> KVM_MP_STATE_HALTED is from KVM_MP_STATE_RUNNABLE?
>>
>> See Paolo's table, it is. So why fix a race which should not be
>> happening in the first place.
>
> The bad transition happens exactly because of the race.
> Are you saying you prefer the solution with cmpxchg?
I think we are past that point in our discussion and should really
separate signal (INIT/SIPI) from state (INIT/SIPI_RECEIVED etc.).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2013-03-06 7:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 21:41 [PATCH v2] KVM: x86: Convert INIT and SIPI signals into synchronously handled requests Jan Kiszka
2013-03-04 23:00 ` Jan Kiszka
2013-03-05 7:57 ` Gleb Natapov
2013-03-05 8:24 ` Jan Kiszka
2013-03-05 8:46 ` Gleb Natapov
2013-03-05 9:12 ` Jan Kiszka
2013-03-05 9:37 ` Gleb Natapov
2013-03-05 10:50 ` Paolo Bonzini
2013-03-05 13:25 ` Jan Kiszka
2013-03-05 13:33 ` Gleb Natapov
2013-03-05 13:28 ` Gleb Natapov
2013-03-05 23:16 ` Marcelo Tosatti
2013-03-06 0:01 ` Marcelo Tosatti
2013-03-06 0:06 ` Marcelo Tosatti
2013-03-06 6:12 ` Paolo Bonzini
2013-03-06 7:57 ` Jan Kiszka [this message]
2013-03-06 21:30 ` Marcelo Tosatti
2013-03-06 21:39 ` Jan Kiszka
2013-03-06 21:50 ` Marcelo Tosatti
2013-03-06 21:58 ` Jan Kiszka
2013-03-06 21:19 ` Marcelo Tosatti
2013-03-06 22:43 ` Paolo Bonzini
2013-03-06 23:04 ` Marcelo Tosatti
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=5136F702.4070101@web.de \
--to=jan.kiszka@web.de \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox