From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH v3 4/4] KVM: x86: Add support for local interrupt requests from userspace Date: Fri, 26 Jun 2015 10:49:09 +0200 Message-ID: <558D1205.8020601@redhat.com> References: <1433289107-20638-1-git-send-email-srutherford@google.com> <1433289107-20638-4-git-send-email-srutherford@google.com> <556ECB0D.2060709@redhat.com> <20150626002609.GA15825@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Steve Rutherford Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39435 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751568AbbFZItM (ORCPT ); Fri, 26 Jun 2015 04:49:12 -0400 In-Reply-To: <20150626002609.GA15825@google.com> Sender: kvm-owner@vger.kernel.org List-ID: On 26/06/2015 02:26, Steve Rutherford wrote: > 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)). I think B is okay to do. Later if needed we can make it possible for userspace to mmap the LAPIC page instead of using the APIC state ioctl. Paolo