From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ur6v8-0001nA-Nm for qemu-devel@nongnu.org; Mon, 24 Jun 2013 09:35:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ur6v7-0000ae-1l for qemu-devel@nongnu.org; Mon, 24 Jun 2013 09:35:02 -0400 Received: from mail-ye0-x234.google.com ([2607:f8b0:4002:c04::234]:45391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ur6v6-0000aO-Tz for qemu-devel@nongnu.org; Mon, 24 Jun 2013 09:35:00 -0400 Received: by mail-ye0-f180.google.com with SMTP id r11so236135yen.39 for ; Mon, 24 Jun 2013 06:35:00 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20130624130642.GJ18508@redhat.com> References: <1371737338-25148-1-git-send-email-aik@ozlabs.ru> <1371747090.32709.61.camel@ul30vt.home> <51C3B2E4.7000807@ozlabs.ru> <1371782063.30572.74.camel@ul30vt.home> <51C3BF3E.20901@ozlabs.ru> <1371789981.30572.114.camel@ul30vt.home> <20130624071338.GZ5832@redhat.com> <87sj07bsf3.fsf@codemonkey.ws> <20130624130642.GJ18508@redhat.com> Date: Mon, 24 Jun 2013 08:34:52 -0500 Message-ID: <87hagnhbsz.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] RFC kvm irqfd: add directly mapped MSI IRQ support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: "Michael S . Tsirkin" , Alexey Kardashevskiy , Alexander Graf , qemu-devel , qemu-trivial@nongnu.org, Alex Williamson , qemu-ppc@nongnu.org, Paolo Bonzini , Paul Mackerras , David Gibson Gleb Natapov writes: > On Mon, Jun 24, 2013 at 07:32:32AM -0500, Anthony Liguori wrote: >> Gleb Natapov writes: >> >> This should be a per-device mapping, yes. But I'm not sure that VCPUs >> should even see anything. I don't think a VCPU can generate an MSI >> interrupt by writing to this location. >> > No, and lower 4k of this space is where APIC is mapped as seen from CPU. >> Is there anything that prevents us from using IRQFDs corresponding to >> the target of an MSI mapping and get rid of the MSI info in the kernel? >> > Again, you assume that x86 has some pin that MSI triggers. This is not > the case; address/data is minimum that is needed to inject interrupt > there (or moving APIC into userspace, since this is where "translation" > is happening). An APIC message contains: 1) Destination Mode 2) Delivery mode 3) Level 4) Trigger mode 5) Vector 6) Destination Which is more or less what the MSI addr/data pair encodes. But we can certainly have a userspace interface to inject such a message into the LAPICs. In fact, this is more or less what KVM_SIGNAL_MSI is doing except that it's called MSI and encodes things in an addr/pair. Such an interface would also allow for a QEMU implementation of an IO APIC while still having the in-kernel LAPIC. It would also allow QEMU to do per-device MSI decoding. Isn't this more or less what Avi's previous proposal was around changing the APIC interfaces to userspace? Regards, Anthony Liguori > >> It seems like the only sane way to actually support (2) and (3). >> >> Regards, >> >> Anthony Liguori > > -- > Gleb.