Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Jun 2014 18:55:53 -0700
From:      Neel Natu <neelnatu@gmail.com>
To:        Ryan Stone <rysto32@gmail.com>
Cc:        "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org>
Subject:   Re: SR-IOV Patch Series 2/7: bhyve integration
Message-ID:  <CAFgRE9GPqvw-BNbMnUP3oiJOimC5BDnJ2vqVjxNedGMjP_UBMw@mail.gmail.com>
In-Reply-To: <CAFMmRNx9hd2RM9AO9hKFs2fLdJChTkx5f-5m41dSM29wwT1euA@mail.gmail.com>
References:  <CAFMmRNx9hd2RM9AO9hKFs2fLdJChTkx5f-5m41dSM29wwT1euA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ryan,

On Mon, May 26, 2014 at 6:51 PM, Ryan Stone <rysto32@gmail.com> wrote:
> The bhyve work to interoperate is quite simple.  PCI Passthrough
> through the ppt driver works just fine with SR-IOV VFs.  The three
> changes are:
>
> - allow ppt devices to detach.  This would happen if the administrator
> destroyed VFs with iovctl -D
> - allow the SR-IOV infrastructure to force the ppt driver to attach to
> certain devices by using the special BUS_PROBE_NOWILDCARD return value
> from device_probe().  This will have no effect on regular devices, but
> the SR-IOV infrastructure can create VF devices in a way where
> BUS_PROBE_NOWILDCARD will match the device.  This allows passthrough
> of a given VF to be configured through iovctl (see ioctl.conf(5) for
> an example of how to do this).
> - Currently if vmm.ko is loaded and no ppt devices are present, the
> IOMMU is not enabled.  If VFs are subsequently created as passthrough
> devices it will not be possible to pass them through to VMs.  This
> patch adds a new tunable that will force the IOMMU to be enabled.
>
> Note: Currently ppt suffers from a lack of locking.  This is now a
> problem because ppt devices can be destroyed, so there would be races
> here.  I tried to address this by adding a mutex but that failed in
> ways that I could not figure out how to resolve (basically, some parts
> of ppt are called into from within a critical section, so a spinlock
> is needed, but other parts of ppt call into the VM subsystem to do
> M_WAITOK allocations, so an sx lock is needed.  It wasn't at all
> obvious to me how to resolve that conflict, so I'm hoping that a more
> experienced bhyve person has an idea).
>

Your changes look good.

Also, yes, locking is now an issue. Let me try a couple of things and
see how to fix this properly.

best
Neel

>
> http://people.freebsd.org/~rstone/patches/iov/0004-Allow-passthrough-devices-to-be-hinted.patch
> [PATCH 04/21] Allow passthrough devices to be hinted.
>
> Allow the ppt driver to attach to devices that were hinted to be
> passthrough devices by the PCI code creating them with a driver
> name of "ppt".
>
> Add a tunable that allows the IOMMU to be forced to be used.  With
> SR-IOV passthrough devices the VFs may be created after vmm.ko is
> loaded.  The current code will not initialize the IOMMU in that
> case, meaning that the passthrough devices can't actually be used.
> ---
>  sys/amd64/vmm/io/ppt.c | 72 +++++++++++++++++++++++++++-----------------------
>  sys/amd64/vmm/vmm.c    |  7 ++++-
> _______________________________________________
> freebsd-virtualization@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFgRE9GPqvw-BNbMnUP3oiJOimC5BDnJ2vqVjxNedGMjP_UBMw>