From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, KVM <kvm@vger.kernel.org>,
Gleb Natapov <gleb@redhat.com>,
RT <linux-rt-users@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: Kick VCPU outside PIC lock again
Date: Wed, 24 Feb 2010 12:41:42 +0200 [thread overview]
Message-ID: <4B850266.3070706@redhat.com> (raw)
In-Reply-To: <4B84FF5C.5090603@siemens.com>
On 02/24/2010 12:28 PM, Jan Kiszka wrote:
> Jan Kiszka wrote:
>
>> Avi Kivity wrote:
>>
>>> On 02/24/2010 12:13 PM, Jan Kiszka wrote:
>>>
>>>>
>>>>
>>>>> I see. Won't we hit the same issue when we call pic functions from
>>>>> atomic context during the guest entry sequence?
>>>>>
>>>>>
>>>>>
>>>> If there are such call paths, for sure. What concrete path(s) do you
>>>> have in mind?
>>>>
>>>>
>>>>
>>> vcpu_enter_guest() -> inject_pending_event() ->
>>> kvm_cpu_{has,get}_interrupt() -> various pic functions if you're unlucky.
>>>
>> But do they kick anyone or just check/pull information? Never saw any
>> warnings during my tests last year (granted: with older -rt and kvm
>> versions).
>>
> Mmh, they could if there is> 1 IRQ pending. Guess this just never
> triggered in real life due to typical APIC use and low IRQ load during
> PIC times in my tests.
>
We could just ignore the wakeup in this path. It's called in vcpu
context, so obviously the vcpu is awake and kicking it will only hurt
your feet.
Longer term, we should clear up this mess. One possible path is to move
the pic/lapic/injection stuff out of the the critical section, and use
vcpu->requests to close the race between querying the pic/lapic and
entering the guest.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-02-24 10:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100217135901.331576359@linutronix.de>
2010-02-23 19:18 ` [patch] x86: kvm: Convert i8254/i8259 locks to raw_spinlocks Jan Kiszka
2010-02-23 22:23 ` Thomas Gleixner
2010-02-24 9:41 ` [PATCH] KVM: x86: Kick VCPU outside PIC lock again Jan Kiszka
2010-02-24 9:48 ` Avi Kivity
2010-02-24 9:54 ` Jan Kiszka
2010-02-24 10:04 ` Avi Kivity
2010-02-24 10:13 ` Jan Kiszka
2010-02-24 10:17 ` Avi Kivity
2010-02-24 10:22 ` Jan Kiszka
2010-02-24 10:27 ` Avi Kivity
2010-02-24 10:31 ` Jan Kiszka
2010-02-24 10:28 ` Jan Kiszka
2010-02-24 10:41 ` Avi Kivity [this message]
2010-02-24 11:42 ` Jan Kiszka
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=4B850266.3070706@redhat.com \
--to=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=tglx@linutronix.de \
/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).