From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn2Gp-0004NC-KU for qemu-devel@nongnu.org; Wed, 21 May 2014 04:53:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wn2Ge-0002tW-Hv for qemu-devel@nongnu.org; Wed, 21 May 2014 04:53:07 -0400 Received: from mail-pb0-f54.google.com ([209.85.160.54]:61555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn2Ge-0002tO-CU for qemu-devel@nongnu.org; Wed, 21 May 2014 04:52:56 -0400 Received: by mail-pb0-f54.google.com with SMTP id jt11so1221135pbb.13 for ; Wed, 21 May 2014 01:52:55 -0700 (PDT) Message-ID: <537C6964.2050708@ozlabs.ru> Date: Wed, 21 May 2014 18:52:52 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1400147999-4793-1-git-send-email-aik@ozlabs.ru> <1400147999-4793-9-git-send-email-aik@ozlabs.ru> <537C6680.20601@suse.de> In-Reply-To: <537C6680.20601@suse.de> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 8/8] spapr_pci: Use XICS interrupt allocator and do not cache interrupts in PHB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org On 05/21/2014 06:40 PM, Alexander Graf wrote: > > On 15.05.14 11:59, Alexey Kardashevskiy wrote: >> Currently SPAPR PHB keeps track of all allocated MSI/MISX interrupt as >> XICS used to be unable to reuse interrupts which becomes a problem for >> dynamic MSI reconfiguration which is happening on guest driver reload or >> PCI hot (un)plug. Another problem is that PHB has a limit of devices >> supporting MSI/MSIX (SPAPR_MSIX_MAX_DEVS=32) and there is no good reason >> for that. >> >> This makes use of new XICS ability to reuse interrupts. >> >> This removes cached MSI configuration from SPAPR PHB so the first IRQ number >> of a device is stored in MSI/MSIX config space so there is no need to store >> this anywhere else. From now on, SPAPR PHB only keeps flags telling what >> type >> of interrupt for which device it has configured in order to return error if >> (for example) MSIX was enabled and the guest is trying to disable MSI which >> it has not enabled. >> >> This removes a limit for the maximum number of MSIX-enabled devices per PHB, >> now XICS and PCI bus capacity are the only limitation. >> >> This changes migration stream as it fixes vmstate_spapr_pci_msi::name >> which was >> wrong since the beginning. >> >> This fixed traces to be more informative. >> >> Signed-off-by: Alexey Kardashevskiy >> --- >> >> In reality either MSIX or MSI is enabled, never both. So I could remove >> msi/msix >> bitmaps from this patch, would it make sense? > > Is this a hard requirement? Does a device have to choose between MSIX and > MSI or could it theoretically have both enabled? Is this a PCI limitation, > a PAPR/XICS limitation or just a limitation of your implementation? My implementation does not have this limitation, I asked if I can simplify code by introducing one :) I cannot see any reason why PCI cannot have both MSI and MSIX enabled but it does not seem to be used by anyone => cannot debug and confirm. PAPR spec assumes that if the guest tries enabling MSIX when MSI is already enabled, this is a "change", not enabling both types. But it also says MSI and MSIX vector numbers are not shared. Hm. -- Alexey