From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqM2h-0000Vo-Ur for qemu-devel@nongnu.org; Wed, 13 Apr 2016 10:45:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqM2c-0003yB-QA for qemu-devel@nongnu.org; Wed, 13 Apr 2016 10:45:19 -0400 Received: from mout.web.de ([212.227.17.11]:54760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqM2c-0003y5-D1 for qemu-devel@nongnu.org; Wed, 13 Apr 2016 10:45:14 -0400 References: <1460366363-4589-1-git-send-email-peterx@redhat.com> <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> From: Jan Kiszka Message-ID: <570E5B66.9000700@web.de> Date: Wed, 13 Apr 2016 07:44:54 -0700 MIME-Version: 1.0 In-Reply-To: <20160413100643.GG17558@pxdev.xzpeter.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Peter Xu 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 2016-04-13 03:06, Peter Xu wrote: > On Tue, Apr 12, 2016 at 08:39:21PM -0700, Jan Kiszka wrote: >> On 2016-04-12 20:33, Peter Xu wrote: >>> On Tue, Apr 12, 2016 at 08:39:02AM -0700, Jan Kiszka wrote: >>>> On 2016-04-12 02:02, Peter Xu wrote: >>> >>> [...] >>> >>>>> Yes, I should consider other x86 platforms like AMD. Thanks to point >>>>> out. It seems that there are many places in the patchset that lacks >>>>> thorough consideration about this. Will try to fix them in next >>>>> version. >>>>> >>>>> Regarding to the above MSI solution: I'd say it is a good way to >>>>> hide everything else behind. However, since we introduced one extra >>>>> layer (MSI) which actually does not exist, not sure there would be >>>>> problem too. Also, I feel it a little bit hacky if we "create" one >>>>> MSI out of the air... For example, if someone tries to capture MSIs >>>>> from QEMU inside in the APIC memory writes, he will see something he >>>>> cannot explain if he never knows this hack's there. Considering the >>>>> above, I would prefer hooks, or better to provide a callback (a >>>>> function pointer that others like AMD can override) to do the >>>>> translation. How do you think? >>>> >>>> The HPET does send MSIs, and I'm not sure how much different the >>>> IOAPIC's message actually is. In any case, modelling it as MSI is >>>> neither adding incorrectness nor making the code more complex (in fact, >>>> the contrary is true!). Last but not least, it would be trivial to >>>> filter out non-PCI MSI sources if we wanted to trace only PCI - because >>>> we need to identify the origin anyway for remapping purposes. So, >>>> explicit hooking looks like the wrong way to me. >>> >>> I am just not sure about the difference between IOAPIC's messages >>> and MSI ones. For now, they seems very alike. However, I am not sure >>> whether it would be not alike in the future. E.g., if one day, we >>> extend APIC bus to support more than 255 CPUs (could it? I do not >>> know for sure), here if we are with this "MSI layer", we would not >>> be able to do that, since MSI only support 8 bits for destination ID >>> field. That's my only worry now. If you (or Radim? or anyone more >>> experienced on this than me) can confirm that this would never be a >>> problem, I'd be glad to take the MSI way. >> >> That's one of the reason why we need IR: >255 is only possible this way, >> because it requires x2APIC and that requires IR (see Intel spec). So, >> IOAPIC messages will then always travel via VT-d. No need to worry at all. > > 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. > > Btw, if to use the way you suggested, the patch content would > possibly be very alike the one you and Rita has posted, which is: > > https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg01933.html > > I will only pick up those lines I needed in supporting IOAPIC. If > so, do you mind I add your s-o-b as well above mine (maybe add > Rita's too)? If a patch is almost identical, add your [Peter: my changes...] line and your signed of to it. If it is more modified, claim authorship and just refer to the original authors in the commit log. Jan