On Wed, Aug 19, 2009 at 11:37:16PM +0300, Avi Kivity wrote: > On 08/19/2009 09:26 PM, Gregory Haskins wrote: >>>> This is for things like the setup of queue-pairs, and the >>>> transport of door-bells, and ib-verbs. I am not on the team >>>> doing that work, so I am not an expert in this area. What I do >>>> know is having a flexible and low-latency signal-path was deemed >>>> a key requirement. >>>> >>>> >>> That's not a full bypass, then. AFAIK kernel bypass has userspace >>> talking directly to the device. >>> >> Like I said, I am not an expert on the details here. I only work >> on the vbus plumbing. FWIW, the work is derivative from the >> "Xen-IB" project >> >> http://www.openib.org/archives/nov2006sc/xen-ib-presentation.pdf >> >> There were issues with getting Xen-IB to map well into the Xen >> model. Vbus was specifically designed to address some of those >> short-comings. > > Well I'm not an Infiniband expert. But from what I understand VMM > bypass means avoiding the call to the VMM entirely by exposing > hardware registers directly to the guest. The original IB VMM bypass work predates SR-IOV (i.e., does not assume that the adapter has multiple hardware register windows for multiple devices). The way it worked was to split all device operations into `privileged' and `non-privileged'. Privileged operations such as mapping and pinning memory went through the hypervisor. Non-privileged operations such reading or writing previously mapped memory went directly to the adpater. Now-days with SR-IOV devices, VMM bypass usually means bypassing the hypervisor completely. Cheers, Muli -- Muli Ben-Yehuda | muli@xxxxxxxxxx | +972-4-8281080 Manager, Virtualization and Systems Architecture Master Inventor, IBM Haifa Research Laboratory -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
