From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Rutherford Subject: Re: [PATCH v3 4/4] KVM: x86: Add support for local interrupt requests from userspace Date: Thu, 4 Jun 2015 13:21:55 -0700 Message-ID: <20150604202155.GA22371@google.com> References: <1433289107-20638-1-git-send-email-srutherford@google.com> <1433289107-20638-4-git-send-email-srutherford@google.com> <556ECB0D.2060709@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Paolo Bonzini Return-path: Received: from mail-ig0-f181.google.com ([209.85.213.181]:33692 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752199AbbFDUWJ (ORCPT ); Thu, 4 Jun 2015 16:22:09 -0400 Received: by igbpi8 with SMTP id pi8so589384igb.0 for ; Thu, 04 Jun 2015 13:22:08 -0700 (PDT) Content-Disposition: inline In-Reply-To: <556ECB0D.2060709@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jun 03, 2015 at 11:38:21AM +0200, Paolo Bonzini wrote: > However, why is the roundtrip to userspace necessary? Could you pass > the extint index directly as an argument to KVM_INTERRUPT? It's > backwards-compatible, because KVM_INTERRUPT so far could not be used > together with an in-kernel LAPIC. If you could do that, you could also > avoid the new userspace_extint_available field. This is possible, and definitely simpler, but not accurate to the spec. In general, the PIC fires an INT, which leads to the CPU responding with and INTA, and fetching the interrupt vector. It might not be strictly necessary for this handshake to occur, but it is how the hardware did it originally. In certain cases, having the interface modelled after the hardware is convenient. For example, devices can send external interrupt MSIs, which require an Interrupt Ack to fetch the vector. They're a bit weird, and I have absolutely no idea why someone would want these, but they are a definitely a thing. Looking back at KVM though, it doesn't look like KVM even supports these, so this may not be a real issue. Eliding the roundtrip might be acceptable. It's certainly simpler. > Userspace can figure out who's the BSP. The rendez-vous between the > irqchip and the BSP's VCPU thread is still needed, but it can be done > entirely in userspace. Good point. I'll push this up into userspace.