Marc-André Lureau <[email protected]> writes: > Hi > > On Fri, Jan 29, 2016 at 4:59 PM, Markus Armbruster <[email protected]> wrote: >> [email protected] writes: >> >>> From: Marc-André Lureau <[email protected]> >>> >>> Call ivshmem_setup_interrupts() with or without MSI, always allocate >>> msi_vectors that is going to be used in all case in the following patch. >>> >>> Signed-off-by: Marc-André Lureau <[email protected]> >>> --- >>> hw/misc/ivshmem.c | 27 +++++++++++++++++---------- >>> 1 file changed, 17 insertions(+), 10 deletions(-) >>> >>> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c >>> index dcfc8cc..11780b1 100644 >>> --- a/hw/misc/ivshmem.c >>> +++ b/hw/misc/ivshmem.c >>> @@ -768,19 +768,28 @@ static void ivshmem_reset(DeviceState *d) >>> ivshmem_use_msix(s); >>> } >>> >>> -static int ivshmem_setup_msi(IVShmemState * s) >>> +static int ivshmem_setup_interrupts(IVShmemState *s, Error **errp) >>> { >>> - if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) { >>> - return -1; >>> + /* allocate QEMU callback data for receiving interrupts */ >>> + s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector)); >>> + if (!s->msi_vectors) { >> >> Happens exactly when s->vectors is zero. Is that a legitimate >> configuration? > > msix_init_exclusive_bar() already failed with nvectors == 0. However > it is acceptable for !msi to have nvectors == 0. Fixed.
Sounds like I can expect a respin, correct me if I'm wrong. [...]
