| Message ID | 1398741464-21394-1-git-send-email-aik@ozlabs.ru |
|---|---|
| State | New |
| Headers | show |
On 29.04.14 05:17, Alexey Kardashevskiy wrote: > Recently a check for maximum supported MSIX vectors number has been > added. However the check always assumed that MSIX is the only case > and failed on devices which have MSI but do not have MSIX such as > QEMU's PCI Bridge. This results in assert in xics_alloc_block() as > req_num is zero. > > This adds a check for MSI vectors number too. > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> > --- > > I posted recently a memory corruption fix, patch > "spapr_pci: Fix number of returned vectors in ibm, change-msi". > > However it breaks QEMU's PCI bridge so here is a patch. > > I would prepare a patch to replace the one in agrag/ppc-next ad01ba7 > but it has Cc: qemu-stable@nongnu.org in it so I am afraid it could make > it to some other tree already (did not it?). > > Sorry for missing that. This is embarassing :( You're lucky - the patch didn't get out of my queue yet. I've squashed this patch into the previous, broken commit and qemu-stable will only get CC'ed on the resulting, working patch. Alex
On 04/29/2014 07:40 PM, Alexander Graf wrote: > > On 29.04.14 05:17, Alexey Kardashevskiy wrote: >> Recently a check for maximum supported MSIX vectors number has been >> added. However the check always assumed that MSIX is the only case >> and failed on devices which have MSI but do not have MSIX such as >> QEMU's PCI Bridge. This results in assert in xics_alloc_block() as >> req_num is zero. >> >> This adds a check for MSI vectors number too. >> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> >> --- >> >> I posted recently a memory corruption fix, patch >> "spapr_pci: Fix number of returned vectors in ibm, change-msi". >> >> However it breaks QEMU's PCI bridge so here is a patch. >> >> I would prepare a patch to replace the one in agrag/ppc-next ad01ba7 >> but it has Cc: qemu-stable@nongnu.org in it so I am afraid it could make >> it to some other tree already (did not it?). >> >> Sorry for missing that. This is embarassing :( > > You're lucky - No, I am not. Found another bug, please revert this, I'll repost the patch. Sorry :( > the patch didn't get out of my queue yet. I've squashed this > patch into the previous, broken commit and qemu-stable will only get CC'ed > on the resulting, working patch.
> Am 04.05.2014 um 12:28 schrieb Alexey Kardashevskiy <aik@ozlabs.ru>: > >> On 04/29/2014 07:40 PM, Alexander Graf wrote: >> >>> On 29.04.14 05:17, Alexey Kardashevskiy wrote: >>> Recently a check for maximum supported MSIX vectors number has been >>> added. However the check always assumed that MSIX is the only case >>> and failed on devices which have MSI but do not have MSIX such as >>> QEMU's PCI Bridge. This results in assert in xics_alloc_block() as >>> req_num is zero. >>> >>> This adds a check for MSI vectors number too. >>> >>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> >>> --- >>> >>> I posted recently a memory corruption fix, patch >>> "spapr_pci: Fix number of returned vectors in ibm, change-msi". >>> >>> However it breaks QEMU's PCI bridge so here is a patch. >>> >>> I would prepare a patch to replace the one in agrag/ppc-next ad01ba7 >>> but it has Cc: qemu-stable@nongnu.org in it so I am afraid it could make >>> it to some other tree already (did not it?). >>> >>> Sorry for missing that. This is embarassing :( >> >> You're lucky - > > No, I am not. Found another bug, please revert this, I'll repost the patch. > Sorry :( Please post the patch on top of this one. Alex > > >> the patch didn't get out of my queue yet. I've squashed this >> patch into the previous, broken commit and qemu-stable will only get CC'ed >> on the resulting, working patch. > > > -- > Alexey
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index 305f459..c052917 100644 --- a/hw/ppc/spapr_pci.c +++ b/hw/ppc/spapr_pci.c @@ -343,8 +343,20 @@ static void rtas_ibm_change_msi(PowerPCCPU *cpu, sPAPREnvironment *spapr, /* There is no cached config, allocate MSIs */ if (!phb->msi_table[ndev].nvec) { - if (req_num > pdev->msix_entries_nr) { - req_num = pdev->msix_entries_nr; + int max_irqs = 0; + if (ret_intr_type == RTAS_TYPE_MSI) { + max_irqs = msi_nr_vectors_allocated(pdev); + } else if (ret_intr_type == RTAS_TYPE_MSIX) { + max_irqs = pdev->msix_entries_nr; + } + if (!max_irqs) { + error_report("Requested interrupt type %d is not enabled for device#%d", + ret_intr_type, ndev); + rtas_st(rets, 0, -1); /* Hardware error */ + return; + } + if (req_num > max_irqs) { + req_num = max_irqs; } irq = spapr_allocate_irq_block(req_num, false, ret_intr_type == RTAS_TYPE_MSI);
Recently a check for maximum supported MSIX vectors number has been added. However the check always assumed that MSIX is the only case and failed on devices which have MSI but do not have MSIX such as QEMU's PCI Bridge. This results in assert in xics_alloc_block() as req_num is zero. This adds a check for MSI vectors number too. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> --- I posted recently a memory corruption fix, patch "spapr_pci: Fix number of returned vectors in ibm, change-msi". However it breaks QEMU's PCI bridge so here is a patch. I would prepare a patch to replace the one in agrag/ppc-next ad01ba7 but it has Cc: qemu-stable@nongnu.org in it so I am afraid it could make it to some other tree already (did not it?). Sorry for missing that. This is embarassing :( --- hw/ppc/spapr_pci.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)