On Mon, Feb 29, 2016 at 7:40 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.
>
> 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;
> + }
> +
> /* don't print ISR resets */
> if (isr) {
> IVSHMEM_DPRINTF("Set IRQ to %d (%04x %04x)\n",
> @@ -874,6 +879,10 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error
> **errp)
> pci_conf = dev->config;
> pci_conf[PCI_COMMAND] = PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
>
> + /*
> + * Note: we don't use INTx with IVSHMEM_MSI at all, so this is a
> + * bald-faced lie then. But it's a backwards compatible lie.
> + */
> pci_config_set_interrupt_pin(pci_conf, 1);
I am not sure how much of a problem this is. Apparently, other devices
claim interrupt and msi (ich, hda, pvscsi)
Better ask someone more familiar with PCI details.
>
> memory_region_init_io(&s->ivshmem_mmio, OBJECT(s), &ivshmem_mmio_ops, s,
> --
> 2.4.3
>
>
--
Marc-André Lureau
