From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ur70U-0007ck-5e for qemu-devel@nongnu.org; Mon, 24 Jun 2013 09:40:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ur70P-0002oG-UF for qemu-devel@nongnu.org; Mon, 24 Jun 2013 09:40:34 -0400 Date: Mon, 24 Jun 2013 16:41:11 +0300 From: "Michael S. Tsirkin" Message-ID: <20130624134111.GA1109@redhat.com> References: <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> <87hagnhbsz.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87hagnhbsz.fsf@codemonkey.ws> 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: Anthony Liguori Cc: Gleb Natapov , Alexey Kardashevskiy , qemu-devel , Alexander Graf , qemu-trivial@nongnu.org, Alex Williamson , qemu-ppc@nongnu.org, Paolo Bonzini , Paul Mackerras , David Gibson On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote: > 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 While that's not very elegant, I think we can use the existing interface for this: just encode things in a fake "msi message" in the format that kernel expects. > > > >> It seems like the only sane way to actually support (2) and (3). > >> > >> Regards, > >> > >> Anthony Liguori > > > > -- > > Gleb.