kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: "<kvm-ppc@vger.kernel.org>" <kvm-ppc@vger.kernel.org>,
	"Jörg Sommer" <joerg@alea.gnuu.de>,
	"KVM list" <kvm@vger.kernel.org>
Subject: Re: [PATCH 4/4] KVM: PPC: align vcpu_kick with x86
Date: Mon, 12 Dec 2011 11:32:32 -0600	[thread overview]
Message-ID: <4EE63AB0.1030202@freescale.com> (raw)
In-Reply-To: <87C18322-1455-46B5-ACA6-F8786D850C1B@suse.de>

On 12/09/2011 05:15 PM, Alexander Graf wrote:
> 
> On 09.12.2011, at 20:15, Scott Wood wrote:
> 
>> On 12/09/2011 01:10 PM, Alexander Graf wrote:
>>>
>>> On 09.12.2011, at 19:19, Scott Wood <scottwood@freescale.com> wrote:
>>>
>>>> On 12/09/2011 09:26 AM, Alexander Graf wrote:
>>>>> Our vcpu kick implementation differs a bit from x86 which resulted in us not
>>>>> disabling preemption during the kick. Get it a bit closer to what x86 does.
>>>>
>>>> Disabling preemption only matters due to the other bit of functionality
>>>> you brought over -- avoiding kicking the current CPU.
>>>
>>> Nope, I had BUG_ON warnings in the kick code because preemption was on.
>>
>> Coming from where?
> 
> From here:
> 
> BUG: using smp_processor_id() in preemptible [00000000] code: qemu-system-ppc/17448
> caller is .smp_mpic_message_pass+0x88/0x10c
> Call Trace:
> [c000000078d83600] [c000000000013e70] .show_stack+0x6c/0x16c (unreliable)
> [c000000078d836b0] [c00000000037b614] .debug_smp_processor_id+0xe4/0x11c
> [c000000078d83740] [c000000000048988] .smp_mpic_message_pass+0x88/0x10c
> [c000000078d837d0] [c00000000002f2b4] .smp_send_reschedule+0x4c/0x80
> [c000000078d83850] [d000000005e68984] .kvm_vcpu_kick+0x5c/0x74 [kvm]
> [c000000078d838d0] [d000000005e689d8] .kvm_vcpu_ioctl_interrupt+0x3c/0x54 [kvm]
> [c000000078d83950] [d000000005e68a8c] .kvm_arch_vcpu_ioctl+0x9c/0x21c [kvm]
> [c000000078d83b60] [d000000005e64520] .kvm_vcpu_ioctl+0x7c/0x6b8 [kvm]
> [c000000078d83c20] [d000000005e64c2c] .kvm_vcpu_compat_ioctl+0xd0/0xfc [kvm]
> [c000000078d83cd0] [c0000000001be750] .compat_sys_ioctl+0x160/0x1864
> [c000000078d83e30] [c00000000000988c] syscall_exit+0x0/0x40

Hmm, unless smp_send_reschedule must be called with preemption disabled
(doesn't seem like an obvious requirement, even if callers commonly have
a reason to do so, and the only documentation of it I see is on the ia64
implementation), that seems like a bug in the MPIC IPI implementation.

It wouldn't be an issue (and would make the MPIC driver slightly faster,
too) if the MPIC driver were to use the magic CPU region instead of
manually indexing the non-magic array of per-CPU regions.  Maybe it
doesn't work on all hardware the driver supports?

Not that it matters much here -- we want this patch anyway, because we
want to check that it's not the current CPU.

-Scott


  reply	other threads:[~2011-12-12 17:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-09 15:26 [PATCH 0/4] Fix book3s-pr KVM with preemption Alexander Graf
2011-12-09 15:26 ` [PATCH 1/4] KVM: PPC: Book3s: PR: Disable preemption in vcpu_run Alexander Graf
2011-12-09 18:19   ` Scott Wood
2011-12-09 23:18     ` Alexander Graf
2011-12-13 21:15       ` Scott Wood
2011-12-09 15:26 ` [PATCH 2/4] KVM: PPC: Book3s: PR: No irq_disable " Alexander Graf
2011-12-09 15:26 ` [PATCH 3/4] KVM: PPC: Use get/set for to_svcpu to help preemption Alexander Graf
2011-12-09 15:26 ` [PATCH 4/4] KVM: PPC: align vcpu_kick with x86 Alexander Graf
2011-12-09 18:19   ` Scott Wood
2011-12-09 19:10     ` Alexander Graf
2011-12-09 19:15       ` Scott Wood
2011-12-09 23:15         ` Alexander Graf
2011-12-12 17:32           ` Scott Wood [this message]
2011-12-23 12:56             ` Alexander Graf
2011-12-23 21:50               ` Benjamin Herrenschmidt

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=4EE63AB0.1030202@freescale.com \
    --to=scottwood@freescale.com \
    --cc=agraf@suse.de \
    --cc=joerg@alea.gnuu.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).