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, 25 Jun 2015 17:26:09 -0700 Message-ID: <20150626002609.GA15825@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-f177.google.com ([209.85.213.177]:36053 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426AbbFZA0O (ORCPT ); Thu, 25 Jun 2015 20:26:14 -0400 Received: by igbiq7 with SMTP id iq7so3410815igb.1 for ; Thu, 25 Jun 2015 17:26:13 -0700 (PDT) Content-Disposition: inline In-Reply-To: <556ECB0D.2060709@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: > 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. Implemented a basic version of this, and ran into some potential issues with this strategy. Supporting PIC masking/unmasking by the CPU/APIC means that either: A) PIC interrupts need to be bufferable in the kernel (with some way of comparing priorities). B) the APIC state needs to be read in order to fetch the bit as to whether or not the PIC is being masked (which I believe can be done from userspace via the APIC state ioctl). C) something hacky that doesn't conform to the PIC spec but still happens to boot common OSes (like buffering the interrupts and injecting them in the order of arrival (which is wrong)). Steve