Thread (1 message) 1 message, 1 author, 2008-11-06

Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support

From: Matthew Wilcox <hidden>
Date: 2008-11-06 22:58:54

On Thu, Nov 06, 2008 at 04:38:40PM -0600, Anthony Liguori wrote:
quoted
It's not clear thats the right solution.  If the VF devices are _only_
going to be used by the guest, then arguably, we don't want to create
pci_devs for them in the host.  (I think it _is_ the right answer, but I
want to make it clear there's multiple opinions on this).
The VFs shouldn't be limited to being used by the guest.

SR-IOV is actually an incredibly painful thing.  You need to have a VF 
driver in the guest, do hardware pass through, have a PV driver stub in 
the guest that's hypervisor specific (a VF is not usable on it's own), 
have a device specific backend in the VMM, and if you want to do live 
migration, have another PV driver in the guest that you can do teaming 
with.  Just a mess.
Not to mention that you basically have to statically allocate them up
front.
What we would rather do in KVM, is have the VFs appear in the host as 
standard network devices.  We would then like to back our existing PV 
driver to this VF directly bypassing the host networking stack.  A key 
feature here is being able to fill the VF's receive queue with guest 
memory instead of host kernel memory so that you can get zero-copy 
receive traffic.  This will perform just as well as doing passthrough 
(at least) and avoid all that ugliness of dealing with SR-IOV in the guest.
This argues for ignoring the SR-IOV mess completely.  Just have the
host driver expose multiple 'ethN' devices.
This eliminates all of the mess of various drivers in the guest and all 
the associated baggage of doing hardware passthrough.

So IMHO, having VFs be usable in the host is absolutely critical because 
I think it's the only reasonable usage model.

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help