Thread (19 messages) 19 messages, 5 authors, 2018-03-07

RE: [PATCH] pci-iov: Add support for unmanaged SR-IOV

From: "Tian, Kevin" <kevin.tian@intel.com>
Date: 2018-03-02 06:54:25
Also in: kvm, linux-pci, lkml

From: Alex Williamson
Sent: Friday, March 2, 2018 4:22 AM
quoted
I am pretty sure that you are describing is true of some, but not for
all. I think the Amazon solutions and the virtio solution are doing
hard partitioning of the part. I will leave it to those guys to speak
for themselves since I don't know anything about the hardware design
of those parts.
I think we'd need device specific knowledge and enablement to be able
to take advantage of any hardware partitioning, otherwise we need to
assume the pf is privileged, as implemented in other sriov devices.

I'm also trying to imagine whether there's a solution via the new
vfio/mdev interface, where the mdev vendor driver would bind to the pf
and effectively present itself as the mdev device.  The vendor driver
could provide sriov capabilities and bear the burden of ensuring that
the pf is used cooperatively.  The only existing mdev vendor drivers are
vGPUs and rely on on-device DMA translation and isolation, such as
through GTTs, but there have been some thoughts on providing IOMMU
based
isolation of mdev/sriov mixed devices (assuming DMA is even required
for userspace management of the pf in this use case).  [Cc Kirti]
Thanks,
Hope not distracting this thread, but above sounds like an interesting
idea. Actually we ever brainstormed similar thought for another 
potential usage - supporting VF live migration. We are already working
on an generic extension to allow state save/restore of mdev instance.
If vendor driver could further wrap pf as a mdev instance, it could 
leverage the same framework for a clean state migration on VF. based
on mmap callback the vendor driver can easily switch back-and-forth
between pass through and trap/emulation of the VF resources. Of
course doing so alone doesn't address all the demands of VF live
migration (e.g. dirty page tracking still requires other techniques), 
but it does pave a way toward a general framework to support VF
live migration.

If above is feasible, finally we could use one mdev framework to
manage both mdev and pf/vf assignment, while providing added
values which are difficult to achieve today. :-)

Thanks
Kevin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help