From patchwork Tue Jul 28 22:05:37 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 6888571 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 8A436C05AC for ; Tue, 28 Jul 2015 22:05:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A9E3020718 for ; Tue, 28 Jul 2015 22:05:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 96E5E205DC for ; Tue, 28 Jul 2015 22:05:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750898AbbG1WFn (ORCPT ); Tue, 28 Jul 2015 18:05:43 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:33551 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750867AbbG1WFm (ORCPT ); Tue, 28 Jul 2015 18:05:42 -0400 Received: by wicmv11 with SMTP id mv11so196349689wic.0 for ; Tue, 28 Jul 2015 15:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=wzPEKt9HIf/3a6pI8FmdEPFdjBuNNs/MJJTaSe/3WBQ=; b=IJMBeVp5JZ+qOwHguHdiJ0UflbtAzK9rPh+LRCmo1PMjbhbwHmA1gB4nmnSuq5U/YO zHY+5IX63u0PAHWOpkBjn+5/ozjXy7zpPoqpdiLFzkNj1NwoFm5vnobxreK4vEiXnTdr Cf5rDH4uxSGFH+hhVCEa40TzMp8WTJC4DYBrjz4kg1zagBy7k2N3VVsFSqlt30geatdc Xj9EvU+c+s9EhQ4AlSiHuORrvO2+MTl+DoUYLOqfyuXq8I3zFkf1gvzV2RGZt/agSyI1 IerabX95tM7+8evcVc1XiQSNEUjyLUsZ8IXjIeaN44/84ZlIguqTGO6Z5rh62WY8veVG Jrtg== X-Received: by 10.180.8.68 with SMTP id p4mr11186483wia.27.1438121141382; Tue, 28 Jul 2015 15:05:41 -0700 (PDT) Received: from [192.168.10.165] (dynamic-adsl-94-39-188-187.clienti.tiscali.it. [94.39.188.187]) by smtp.googlemail.com with ESMTPSA id pn6sm35240681wjb.36.2015.07.28.15.05.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 15:05:40 -0700 (PDT) Subject: Re: [PATCH v5 4/4] KVM: x86: Add support for local interrupt requests from userspace To: Steve Rutherford , KVM list References: <1438039062-3168-1-git-send-email-srutherford@google.com> <1438039062-3168-4-git-send-email-srutherford@google.com> <55B7A6AE.5070001@redhat.com> <20150728190635.GA7460@google.com> From: Paolo Bonzini X-Enigmail-Draft-Status: N1110 Message-ID: <55B7FCB1.1020508@redhat.com> Date: Wed, 29 Jul 2015 00:05:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150728190635.GA7460@google.com> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 28/07/2015 21:06, Steve Rutherford wrote: >>> > > + if (!kvm_run->ready_for_interrupt_injection && >>> > > + ready_for_interrupt_injection) >>> > > + kvm_make_request(KVM_REQ_PIC_UNMASK_EXIT, vcpu); >>> > > + >>> > > + kvm_run->ready_for_interrupt_injection = >>> > > + ready_for_interrupt_injection; >>> > > + } else { >>> > > kvm_run->ready_for_interrupt_injection = >>> > > kvm_arch_interrupt_allowed(vcpu) && >>> > > !kvm_cpu_has_interrupt(vcpu) && >>> > > !kvm_event_needs_reinjection(vcpu); >>> > > + } >>> > > } >>> > > >>> > > static void update_cr8_intercept(struct kvm_vcpu *vcpu) >> > >> > Why is this necessary? Could it just set >> > kvm_run->ready_for_interrupt_injection as in the pic_in_kernel case? > The goal is to couple the interrupt ack cycle as closely as possible > with the injection of the local interrupt (which occur more or less > atomically on real hardware). The idea is to only ever attempt to > inject local interrupts when the CPU/APIC is ready to immediately > accept. Ok, I understand it now. However, you're still not causing an exit when LVT0 changes, are you? post_kvm_run_save is not run until the next exit to userspace, which could be a long time later. So, I think that you do not need KVM_REQ_PIC_UNMASK_EXIT. Instead, you can modify dm_request_for_irq_injection to handle the split-irqchip case, like this: if (!vcpu->run->request_interrupt_window || pic_in_kernel(vcpu->kvm)) return false; if (kvm_cpu_has_interrupt(vcpu)) return false; return (irqchip_split(vcpu->kvm) ? kvm_apic_accept_pic_intr(vcpu) : kvm_arch_interrupt_allowed(vcpu)); This will cause KVM_RUN to return -EINTR, which QEMU happens to handle the same way as KVM_EXIT_IRQ_WINDOW_OPEN. If you prefer the explicit reason, this small change will provide it: Feel free to post v6 of this patch only. Everything else is mostly okay; there are some leftovers here and there (lapic_in_kernel, GET_VECTOR_FROM_USERSPACE) but I can fix that. How is the integration with QEMU going? With this latest iteration it should be relatively easy. Paolo --- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 5ef2560075bf..3269169233fb 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6720,8 +6720,8 @@ static int vcpu_run(struct kvm_vcpu *vcpu) kvm_inject_pending_timer_irqs(vcpu); if (dm_request_for_irq_injection(vcpu)) { - r = -EINTR; - vcpu->run->exit_reason = KVM_EXIT_INTR; + r = 0; + vcpu->run->exit_reason = KVM_EXIT_IRQ_WINDOW_OPEN; ++vcpu->stat.request_irq_exits; break; }