[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <9184057F7FC11744A2107296B6B8EB1E44721113@fmsmsx101.amr.corp.intel.com>
Date: Wed, 19 Sep 2018 22:25:03 +0000
From: "Eads, Gage" <gage.eads@...el.com>
To: "Raj, Ashok" <ashok.raj@...el.com>,
Alex Williamson <alex.williamson@...hat.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
Joerg Roedel <joro@...tes.org>,
Bjorn Helgaas <helgaas@...nel.org>,
"Alan Cox" <gnomes@...rguk.ukuu.org.uk>
Subject: RE: [PATCH] vfio/pci: Some buggy virtual functions incorrectly
report 1 for intx.
> This looks good and also addresses Alan's concern that don't silently hide under
> the rug for all devices. We'll also queue it for testing just to confirm and keep
> you posted.
>
> Reviewed-by: Ashok Raj <ashok.raj@...el.com>
>
Hi Alex,
I've confirmed that the patch works as intended for the 8086:270c device, and negative tested the warning by commenting out the device's entry in known_bogus_vf_intx_pin.
For what it's worth, my positive test case - launching a QEMU VM with a VFIO-owned 0x270c device - did not trigger the warning. This is because the change to vfio_pci_config.c caused QEMU to read a PCI_INTERRUPT_PIN value of 0, and so didn't execute a codepath that calls vfio_pci_get_irq_count(). Instead, I used a simple C program that calls the VFIO_DEVICE_GET_IRQ_INFO ioctl for negative testing.
Also, there's one typo in the comment: 'quite' -> 'quiet'
Tested-by: Gage Eads <gage.eads@...el.com>
Thanks,
Gage
Powered by blists - more mailing lists