From: Jan Kiszka <jan.kiszka@siemens.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Avi Kivity <avi@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [PATCH 17/22] kvm: Move irqchip event processing out of inner loop
Date: Mon, 31 Jan 2011 17:41:24 +0100 [thread overview]
Message-ID: <4D46E634.30109@siemens.com> (raw)
In-Reply-To: <20110131163858.GA18827@redhat.com>
On 2011-01-31 17:38, Gleb Natapov wrote:
> On Mon, Jan 31, 2011 at 04:40:34PM +0100, Jan Kiszka wrote:
>> On 2011-01-31 14:04, Jan Kiszka wrote:
>>> On 2011-01-31 12:36, Jan Kiszka wrote:
>>>> On 2011-01-31 11:08, Avi Kivity wrote:
>>>>> On 01/27/2011 03:10 PM, Jan Kiszka wrote:
>>>>>> Align with qemu-kvm and prepare for IO exit fix: There is no need to run
>>>>>> kvm_arch_process_irqchip_events in the inner VCPU loop. Any state change
>>>>>> this service processes will first cause an exit from kvm_cpu_exec
>>>>>> anyway. And we will have to reenter the kernel on IO exits
>>>>>> unconditionally, something that the current logic prevents.
>>>>>>
>>>>>> Signed-off-by: Jan Kiszka<jan.kiszka@siemens.com>
>>>>>> ---
>>>>>> kvm-all.c | 11 ++++++-----
>>>>>> 1 files changed, 6 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/kvm-all.c b/kvm-all.c
>>>>>> index 5bfa8c0..46ecc1c 100644
>>>>>> --- a/kvm-all.c
>>>>>> +++ b/kvm-all.c
>>>>>> @@ -892,6 +892,12 @@ int kvm_cpu_exec(CPUState *env)
>>>>>>
>>>>>> DPRINTF("kvm_cpu_exec()\n");
>>>>>>
>>>>>> + if (kvm_arch_process_irqchip_events(env)) {
>>>>>> + env->exit_request = 0;
>>>>>> + env->exception_index = EXCP_HLT;
>>>>>> + return 0;
>>>>>> + }
>>>>>> +
>>>>>> do {
>>>>>> #ifndef CONFIG_IOTHREAD
>>>>>> if (env->exit_request) {
>>>>>> @@ -901,11 +907,6 @@ int kvm_cpu_exec(CPUState *env)
>>>>>> }
>>>>>
>>>>> We check for ->exit_request here
>>>>>
>>>>>> #endif
>>>>>>
>>>>>> - if (kvm_arch_process_irqchip_events(env)) {
>>>>>> - ret = 0;
>>>>>> - break;
>>>>>> - }
>>>>>> -
>>>>>
>>>>> But this checks for ->interrupt_request. What ensures that we exit when
>>>>> ->interrupt_request is set?
>>>>
>>>> Good question, need to check again. But if that turns out to be an
>>>> issue, qemu-kvm would be broken as well. I'm just aligning the code here.
>>>>
>>>
>>> The only thing we miss by moving process_irqchip_events is a self-INIT
>>> of an AP - if such thing exists in real life. In that case, the AP would
>>> cause a reset of itself, followed by a transition to HALT state.
>>
>> I checked again with the Intel spec, and a self-INIT is invalid (at
>> least when specified via shorthand). So I'm under the impression now
>> that we can safely ignore this case and leave the patch as is.
>>
>> Any different views?
>>
> IIRC if you don't use shorthand you can send INIT to self.
We didn't care so far (in qemu-kvm), do you think we should?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2011-01-31 16:41 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-27 13:09 [Qemu-devel] [PATCH 00/22] [uq/master] Patch queue, part II Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 01/22] Prevent abortion on multiple VCPU kicks Jan Kiszka
2011-01-31 9:44 ` [Qemu-devel] " Avi Kivity
2011-01-31 11:19 ` Jan Kiszka
2011-01-31 13:16 ` Avi Kivity
2011-01-27 13:09 ` [Qemu-devel] [PATCH 02/22] Stop current VCPU on synchronous reset requests Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 03/22] Process vmstop requests in IO thread Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 04/22] Leave inner main_loop faster on pending requests Jan Kiszka
2011-01-31 9:52 ` [Qemu-devel] " Avi Kivity
2011-01-31 11:22 ` Jan Kiszka
2011-01-31 13:17 ` Avi Kivity
2011-01-31 14:32 ` Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 05/22] kvm: Report proper error on GET_VCPU_MMAP_SIZE failures Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 06/22] kvm: Drop redundant kvm_enabled from kvm_cpu_thread_fn Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 07/22] kvm: Handle kvm_init_vcpu errors Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 08/22] kvm: Provide sigbus services arch-independently Jan Kiszka
2011-01-27 16:39 ` [Qemu-devel] " Paolo Bonzini
2011-01-30 14:51 ` Alexander Graf
2011-01-27 13:09 ` [Qemu-devel] [PATCH 09/22] Refactor signal setup functions in cpus.c Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 10/22] kvm: Set up signal mask also for !CONFIG_IOTHREAD Jan Kiszka
2011-01-28 8:08 ` [Qemu-devel] " Paolo Bonzini
2011-01-27 13:09 ` [Qemu-devel] [PATCH 11/22] kvm: Refactor qemu_kvm_eat_signals Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 12/22] kvm: Call qemu_kvm_eat_signals also under !CONFIG_IOTHREAD Jan Kiszka
2011-01-28 8:09 ` [Qemu-devel] " Paolo Bonzini
2011-02-01 12:38 ` Marcelo Tosatti
2011-02-01 12:49 ` Marcelo Tosatti
2011-02-01 13:21 ` Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 13/22] Set up signalfd " Jan Kiszka
2011-01-28 8:11 ` [Qemu-devel] " Paolo Bonzini
2011-01-27 13:09 ` [Qemu-devel] [PATCH 14/22] kvm: Fix race between timer signals and vcpu entry under !IOTHREAD Jan Kiszka
2011-01-27 14:20 ` [Qemu-devel] [PATCH v2 " Jan Kiszka
2011-01-27 14:33 ` [Qemu-devel] [PATCH v3 " Jan Kiszka
2011-01-31 10:03 ` [Qemu-devel] " Avi Kivity
2011-01-31 11:27 ` Jan Kiszka
2011-01-31 12:13 ` Stefan Hajnoczi
2011-01-31 12:18 ` Jan Kiszka
2011-01-31 13:35 ` Stefan Hajnoczi
2011-01-31 13:22 ` Avi Kivity
2011-01-31 14:31 ` Jan Kiszka
2011-01-31 16:30 ` Avi Kivity
2011-02-01 12:47 ` [Qemu-devel] Re: [PATCH " Marcelo Tosatti
2011-02-01 13:32 ` Jan Kiszka
2011-02-01 13:48 ` Marcelo Tosatti
2011-02-01 13:58 ` Jan Kiszka
2011-02-01 14:10 ` Marcelo Tosatti
2011-02-01 14:21 ` Jan Kiszka
2011-02-01 14:37 ` Jan Kiszka
2011-02-01 14:45 ` Jan Kiszka
2011-01-27 13:09 ` [Qemu-devel] [PATCH 15/22] kvm: Add MCE signal support for !CONFIG_IOTHREAD Jan Kiszka
2011-01-27 13:10 ` [Qemu-devel] [PATCH 16/22] Introduce VCPU self-signaling service Jan Kiszka
2011-02-01 13:14 ` [Qemu-devel] " Marcelo Tosatti
2011-02-01 13:33 ` Jan Kiszka
2011-02-01 13:50 ` Marcelo Tosatti
2011-02-01 13:59 ` Jan Kiszka
2011-01-27 13:10 ` [Qemu-devel] [PATCH 17/22] kvm: Move irqchip event processing out of inner loop Jan Kiszka
2011-01-31 10:08 ` [Qemu-devel] " Avi Kivity
2011-01-31 11:36 ` Jan Kiszka
2011-01-31 13:04 ` Jan Kiszka
2011-01-31 15:40 ` Jan Kiszka
2011-01-31 16:38 ` Gleb Natapov
2011-01-31 16:41 ` Jan Kiszka [this message]
2011-01-31 16:45 ` Jan Kiszka
2011-01-31 16:50 ` Gleb Natapov
2011-01-31 16:52 ` Jan Kiszka
2011-01-31 16:56 ` Gleb Natapov
2011-01-31 18:06 ` [Qemu-devel] [PATCH v2 17&18/22] kvm: Unconditionally reenter kernel after IO exits Jan Kiszka
2011-01-27 13:10 ` [Qemu-devel] [PATCH 18/22] " Jan Kiszka
2011-01-27 13:10 ` [Qemu-devel] [PATCH 19/22] kvm: Remove static return code of kvm_handle_io Jan Kiszka
2011-01-27 13:10 ` [Qemu-devel] [PATCH 20/22] kvm: Leave kvm_cpu_exec directly after KVM_EXIT_SHUTDOWN Jan Kiszka
2011-01-27 13:10 ` [Qemu-devel] [PATCH 21/22] Refactor kvm&tcg function names in cpus.c Jan Kiszka
2011-01-27 13:10 ` [Qemu-devel] [PATCH 22/22] Fix a few coding style violations " Jan Kiszka
2011-01-31 10:12 ` [Qemu-devel] Re: [PATCH 00/22] [uq/master] Patch queue, part II Avi Kivity
2011-01-31 12:03 ` 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=4D46E634.30109@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.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).