From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-rt-users-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Threaded IPIs?
Date: Fri, 27 Jul 2007 07:56:34 +0300 [thread overview]
Message-ID: <46A97B02.6090806@qumranet.com> (raw)
In-Reply-To: <46A8F6F70200005A000283D4-Igcdv/6uVdMHoYOw/+koYqIwWpluYiW7@public.gmane.org>
Gregory Haskins wrote:
> Hi guys,
> While working with the -rt kernel, I have noticed a problem in KVM.
> Specifically, when you stop a VM you sometimes get a "sleep while
> atomic" oopses. It turns out that the issue is related to an
> smp_function_call IPI that KVM does to remotely flush the VMX hardware
> on shutdown. The code tries to acquire the global kvm_lock (which is a
> normal spinlock_t, of course converted to rt_mutex on -rt) from the
> interrupt context of the IPI handler. You know the rest of the
> story....
>
> The obvious solution is to convert the kvm_lock to a raw_spinlock_t.
> However, I really don't want to do this unless we absolutely have to
> since it will just increase latencies for a good portion of the rest of
> KVM.
>
Are you talking about decache_vcpus_from_cpu() that is called from
hardware_disable()? Would having the caller acquire the lock solve the
problem? Then it would be acquired from outside the IPI.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
prev parent reply other threads:[~2007-07-27 4:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 23:33 Threaded IPIs? Gregory Haskins
[not found] ` <46A8F6F70200005A000283D4-Igcdv/6uVdMHoYOw/+koYqIwWpluYiW7@public.gmane.org>
2007-07-27 4:56 ` Avi Kivity [this message]
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=46A97B02.6090806@qumranet.com \
--to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
--cc=ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=linux-rt-users-u79uwXL29TY76Z2rM5mHXA@public.gmane.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