From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXskh-00075K-UF for qemu-devel@nongnu.org; Fri, 25 May 2012 07:32:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXskc-0000zs-UM for qemu-devel@nongnu.org; Fri, 25 May 2012 07:32:15 -0400 Received: from thoth.sbs.de ([192.35.17.2]:33335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXskc-0000za-Kg for qemu-devel@nongnu.org; Fri, 25 May 2012 07:32:10 -0400 Message-ID: <4FBF6DAC.3030608@siemens.com> Date: Fri, 25 May 2012 08:31:56 -0300 From: Jan Kiszka MIME-Version: 1.0 References: <4FBDE6D6.80700@ozlabs.ru> <4FBE2349.6040800@siemens.com> <4FBEDDF3.20108@ozlabs.ru> <4FBEEEA4.2060504@web.de> <4FBEF2C7.4000708@ozlabs.ru> <4FBF6238.7030407@siemens.com> <4FBF6C55.1070603@ozlabs.ru> In-Reply-To: <4FBF6C55.1070603@ozlabs.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Alex Williamson , David Gibson , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Alex Graf On 2012-05-25 08:26, Alexey Kardashevskiy wrote: > 25.05.2012 20:43, Jan Kiszka =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB= : >> On 2012-05-24 23:47, Alexey Kardashevskiy wrote: >>> On 25/05/12 12:29, Jan Kiszka wrote: >>>> On 2012-05-24 22:18, Alexey Kardashevskiy wrote: >>>>> On 24/05/12 22:02, Jan Kiszka wrote: >>>>>> On 2012-05-24 04:44, Alexey Kardashevskiy wrote: >>>>>>> [Found while debugging VFIO on POWER but it is platform independe= nt] >>>>>>> >>>>>>> There is a feature in PCI (>=3D2.3?) to mask/unmask INTx via PCI_= COMMAND and >>>>>>> PCI_STATUS registers. >>>>>> >>>>>> Yes, 2.3 introduced this. Masking is done via command register, ch= ecking >>>>>> if the source was the PCI in question via the status register. The >>>>>> latter is important for supporting IRQ sharing - and that's why we >>>>>> introduced this masking API to the PCI layer. >>>>> >>>>> >>>>> Is not it just a quite small optimization to not to disable interru= pts on all devices which share >>>>> the same IRQ but just on those who fired an interrupt? If so, do PC= I devices really often share >>>>> IRQs? Does not supporting this mean real slowdown on such devices? >>>>> >>>>> As far as I understand, everyone who cares about performance uses M= SI/MSIX, no? >>>> >>>> Not everyone is blessed with MSI-only PCI devices. From my notebook: >>>> >>>> # cat /proc/interrupts >>>> [...] >>>> 22: [...] IO-APIC-fasteoi ehci_hcd:usb1, ehci_hcd:usb2 >>>> >>>> So, if I want to assign one EHCI controller to a guest, I have to >>>> disable the other as well. The same can happen quickly if you attach= a >>>> few legacy PCI adapters to a system and want to pass them through. >>> >>> Why? vfio-pci receives interrupt, disables it, handles it, enables in= terrupt back. Yes, handling is >>> a bit longer and includes passing interrupt to QEMU and then to the g= uest (can be optimized to avoid >>> QEMU) and waiting for EOI notification but this is all the difference. >> >> You can disable the complete IRQ line as you cannot predict when the >> untrusted device driver that VFIO, KVM, or UIO serves will finally >> decide to silence the IRQ reason in hardware. If you did this, you ris= k >> a DoS attack on those other devices. >=20 >=20 > Untrusted device still can pull down (or up? do not remember :) ) > hardware INT# line, stop other devices on this line and you cannot do > anything about it. How does INTx help if the device is that broken? If the untrusted device truly complies to PCI 2.3, we can stop it from pulling that line by setting the generic INTx mask bit. That's the whole reason for this exercise here. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux