From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqcdL-0000O1-4H for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:28:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqcdH-0001SI-SO for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:28:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50872) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqcdH-0001SC-N2 for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:28:11 -0400 Date: Thu, 14 Apr 2016 16:28:02 +0800 From: Peter Xu Message-ID: <20160414082802.GE25961@pxdev.xzpeter.org> References: <1460366363-4589-13-git-send-email-peterx@redhat.com> <570C860A.4060203@web.de> <20160412090239.GA17558@pxdev.xzpeter.org> <570D1696.2080301@web.de> <20160413033304.GB17558@pxdev.xzpeter.org> <570DBF69.2030302@web.de> <20160413100643.GG17558@pxdev.xzpeter.org> <570E5B66.9000700@web.de> <20160414024645.GB25961@pxdev.xzpeter.org> <570F2DC2.1010200@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <570F2DC2.1010200@web.de> Subject: Re: [Qemu-devel] [PATCH v2 12/13] intel_iommu: ioapic: IR support for emulated IOAPIC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net, ehabkost@redhat.com, jasowang@redhat.com, marcel@redhat.com, mst@redhat.com, pbonzini@redhat.com, rkrcmar@redhat.com On Wed, Apr 13, 2016 at 10:42:26PM -0700, Jan Kiszka wrote: > On 2016-04-13 19:46, Peter Xu wrote: > > On Wed, Apr 13, 2016 at 07:44:54AM -0700, Jan Kiszka wrote: > > [...] > >>> One thing I am curious about: I see that in vtd spec 5.1.5.1: > >>> > >>> "RTE bits 10:8 is programmed to 000b (Fixed) to force the SHV > >>> (SubHandle Valid) field as Clear in the interrupt address > >>> generated." > >>> > >>> So... In real IOMMU hardwares, IOAPIC interrupt will finally be > >>> translated to MSI as well? am I understanding it correctly? > >> > >> It will be translated into something that the IR unit can receive - > >> whatever that is technically. Logically, there is no difference to MSIs > >> received from PCI devices. > > > > Ok. I see there are still differences between IOAPIC and MSI, e.g., > > for IOAPIC entries, it has "Interrupt Input Pin Polarity", which is > > bit 13 of the entry, to show whether 1 or 0 is taken as assertion > > for level-triggered interrupts. While in MSI, I assume assertion > > will be 1 always. Can I take it as "obsolete" and we will never use > > it? > > I can't check details right now, but I would recommend studying in the > specs if any of the *receiver* (APIC and IOMMU) can make sense of that > bit at all, and how. Also study (commit logs) if there is a reason why > the bit is unused. Thanks for the advices. Will add this in my todo list. I am guessing that, all devices emulated by QEMU are using 1 as assertions.. It's defined as IOAPIC_LVT_POLARITY in QEMU. As long as I am sure that current QEMU does not use it, I think I can move on to v3 using MSI path, at least to make sure I'm not making things worse, or bringing any functionality loss. > > > > > If to take IOAPIC entries as MSI messages, all these extra bits will > > be dropped (it's dropped in ioapic_service() already, but not sure > > whether we will pick them up in the future). > > What other bits? Besides polarity bit, there is another one IOAPIC_LVT_DELIV_STATUS, which is not used too. But after more careful look, I see this bit is not too relevant if we are talking about translating IOAPIC entries into MSI. Thanks. -- peterx