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 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.