Marc-André Lureau <marcandre.lur...@gmail.com> writes: > Hi > > On Mon, Mar 7, 2016 at 8:25 PM, Markus Armbruster <arm...@redhat.com> wrote: >> The ivshmem device can either use MSI-X or legacy INTx for interrupts. >> >> With MSI-X enabled, peer interrupt events trigger an MSI as they >> should. But software can still raise INTx via interrupt status and >> mask register in BAR 0. This is explicitly prohibited by PCI Local >> Bus Specification Revision 3.0, section 6.8.3.3: >> >> While enabled for MSI or MSI-X operation, a function is prohibited >> from using its INTx# pin (if implemented) to request service (MSI, >> MSI-X, and INTx# are mutually exclusive). >> >> Fix the device model to leave INTx alone when using MSI-X. >> >> Document that we claim to use INTx in config space even when we don't. >> Unlike other devices, ivshmem does *not* use INTx when configured for >> MSI-X and MSI-X isn't enabled by software. >> >> Signed-off-by: Markus Armbruster <arm...@redhat.com> >> --- >> hw/misc/ivshmem.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c >> index cfea151..fc37feb 100644 >> --- a/hw/misc/ivshmem.c >> +++ b/hw/misc/ivshmem.c >> @@ -126,6 +126,11 @@ static void ivshmem_update_irq(IVShmemState *s) >> PCIDevice *d = PCI_DEVICE(s); >> uint32_t isr = s->intrstatus & s->intrmask; >> >> + /* No INTx with msi=off, whether the guest enabled MSI-X or not */ >> + if (ivshmem_has_feature(s, IVSHMEM_MSI)) { >> + return; > > So you probably mean msi=on
You're right. > with that > Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com> Thanks! [...]