linux-kernel - Re: DMAR faults from unrelated device when vfio is used

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Feb 2013 23:23:11 +0100
From:	Richard Weinberger <richard@...ma-star.at>
To:	Alex Williamson <alex.williamson@...hat.com>
Cc:	David Gstir <david@...ma-star.at>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: DMAR faults from unrelated device when vfio is used

Hi,

Am Wed, 06 Feb 2013 15:45:37 -0700
schrieb Alex Williamson <alex.williamson@...hat.com>:

> On Wed, 2013-02-06 at 21:25 +0100, Richard Weinberger wrote:
> > Hi,
> > 
> > Am Wed, 06 Feb 2013 11:47:20 -0700
> > schrieb Alex Williamson <alex.williamson@...hat.com>: 
> > > Does the card work with pci-assign or are both broken?
> > 
> > It works with pci-assign. :-\
> 
> When you tested this, did you detach the group from vfio or use it as
> is?  In your previous message I see this:

I've detached it.

> 03:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host
> Controller [1033:0194] (rev ff)
> 
> /sys/kernel/iommu_groups/7/devices:
> total 0
> lrwxrwxrwx 1 root root 0 Feb  4 10:29 0000:00:1c.0
> -> ../../../../devices/pci0000:00/0000:00:1c.0 lrwxrwxrwx 1 root root
> 0 Feb  4 10:29 0000:00:1c.6
> -> ../../../../devices/pci0000:00/0000:00:1c.6 lrwxrwxrwx 1 root root
> 0 Feb  4 10:29 0000:03:00.0
> -> ../../../../devices/pci0000:00/0000:00:1c.6/0000:03:00.0
> 
> This seemed like a good card to have in my test cache, so I went and
> got one and it works fine for me... but I've been playing with
> pcieport because I don't think we're handling them correctly in vfio.
> 
> Can you provide lspci -vvv -s 1c.6 while the guest is running?  I'm
> going to bet that
> 
> Control: I/O+ Mem+ BusMaster+

Do you want "lspci -vvv -s 1c.6" after attaching 1c.6 to vfio and not
using pci-assign?

> is not set, which it would have been if pci-assign was tested without
> the group bound to vfio.  I think the solution is going to be
> something around white-listing pcieport, which you can easily test
> with a kernel patch like this:
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 12c264d..48a97fb 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -442,7 +442,7 @@ static struct vfio_device
> *vfio_group_get_device(struct vfio
>   * a device.  It's not always practical to leave a device within a
> group
>   * driverless as it could get re-bound to something unsafe.
>   */
> -static const char * const vfio_driver_whitelist[] = { "pci-stub" };
> +static const char * const vfio_driver_whitelist[] = { "pci-stub",
> "pcieport" }; 
>  static bool vfio_whitelisted_driver(struct device_driver *drv)
>  {

If I whitelist pcieport USB3 works within the guests. :-)
Binding 1c.0 and 1c.6 is no longer needed.
Next week I'll run some more tests with USB3 devices.
 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/