public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH v2] KVM: x86: Convert INIT and SIPI signals into synchronously handled requests
Date: Tue, 05 Mar 2013 14:25:51 +0100	[thread overview]
Message-ID: <5135F25F.3080606@siemens.com> (raw)
In-Reply-To: <5135CE12.6080505@redhat.com>

On 2013-03-05 11:50, Paolo Bonzini wrote:
> Il 05/03/2013 10:37, Gleb Natapov ha scritto:
>>>>> Not at all. I'm keeping the state in a single place, mp_state. I just
>>>>> have to make sure that I do not loose asynchronous events - what INIT
>>>>> and SIPI are.
>>>>
>>>> As evident from this code:
>>>>  +           if (vcpu->arch.mp_state == KVM_MP_STATE_INIT_RECEIVED ||
>>>>  +               test_bit(KVM_REQ_INIT, &vcpu->requests)) {
>>>> the state is in two places.
>>> That's just to protect the content of sipi_vector during delivery.
> 
> Is that even needed?  Can we just do an unconditional:
> 
> 	vcpu->arch.sipi_vector = vector;
> 	/* make sure sipi_vector is visible for the receiver */
> 	smp_wmb();
> 	kvm_make_request(KVM_REQ_SIPI, vcpu);
> 	kvm_vcpu_kick(vcpu);
> 
> and check in the request handler that we did get an INIT?
> 
>>> We could drop the complete if clause if we protected that variable differently.
>>
>> I understand why the code is here. I am saying that this is the evidence
>> that the state is in two places.
> 
> I agree with Gleb here.  The state is in two places.  I'm not saying that
> using requests is wrong, it sounds nice especially for nested INIT.  But
> there is something nasty in the patches so far.
> 
> BTW checking the requests in kvm_apic_has_interrupt seems nicer than
> synchronizing in kvm_arch_cpu_runnable; it is a bit ugly to have side
> effects in kvm_arch_cpu_runnable.  Then you can actually _process_
> the requests only in vcpu_enter_guest and kvm_arch_vcpu_ioctl_get_mpstate().
> In kvm_arch_vcpu_ioctl_put_mpstate(), KVM_MP_STATE_SIPI_RECEIVED has to
> become KVM_MP_STATE_INIT_RECEIVED with KVM_REQ_SIPI set.

An INIT or SIPI signal is not really an interrupt in the sense that
kvm_cpu_has_interrupt or kvm_get_apic_interrupt expect (the current
users of kvm_apic_has_interrupt). I think we would move some ugliness
around this way, not yet resolve it.

But it probably makes sense to refactor the kvm_check_init_and_sipi
service to something that the APIC provide (is that what you are
thinking of, Gleb?). That will not reduce the number of places where we
have to check, but it should encapsulate things a bit cleaner.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2013-03-05 13:25 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 [this message]
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
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=5135F25F.3080606@siemens.com \
    --to=jan.kiszka@siemens.com \
    --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