From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1az2dH-0005zr-2U for qemu-devel@nongnu.org; Sat, 07 May 2016 09:51:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1az2dC-00043r-Pj for qemu-devel@nongnu.org; Sat, 07 May 2016 09:50:57 -0400 Received: from mout.web.de ([212.227.15.3]:64054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1az2dC-00043Y-F6 for qemu-devel@nongnu.org; Sat, 07 May 2016 09:50:54 -0400 References: <1462568028-31037-1-git-send-email-rkrcmar@redhat.com> <1462568028-31037-2-git-send-email-rkrcmar@redhat.com> From: Jan Kiszka Message-ID: <572DF2AD.5030703@web.de> Date: Sat, 7 May 2016 15:50:37 +0200 MIME-Version: 1.0 In-Reply-To: <1462568028-31037-2-git-send-email-rkrcmar@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 1/4] apic: add deliver_msi to APICCommonClass List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , qemu-devel@nongnu.org Cc: Paolo Bonzini , "Lan, Tianyu" , Igor Mammedov , Peter Xu , Eduardo Habkost , Richard Henderson On 2016-05-06 22:53, Radim Krčmář wrote: > The only way to send interrupts from outside of APIC devices is to use > the MSI-inspired memory mapped interface. The interface is not > sufficient because interrupt remapping in extended mode can exceed 8 bit > destination ids. > > The proper way to deliver interrupts would be to design a bus (QPI), but > that is a big undertaking. Real IR unit stores excessive bits in the > high work of MSI address register, which would be bit [63:40] in memory s/work/word/ > address space, so I was considering two options: > - a new special address space for APIC to handle MSI-compatible writes > - one callback to the APIC class that delivers extended MSIs > > This patch uses latter option, because it was easier for me, but I think > the former one could be a tad nicer. Makes sense. Eventually, we should also finally untangle the MSI DMA request handling from the xAPIC MMIO processing. The former could become pretty generic (instead of being reimplemented by each APIC flavour), just potentially redirected to an IOMMU when one is present. But that could come as separate patches. Jan