On Wed, Oct 29, 2008 at 12:25:50PM +0200, Muli Ben-Yehuda wrote: > > > You still succeed if KVM_CAP_DEVICE_ASSIGNMENT isn't defined? > > > That means a newer userspace compiled on an older kernel will > > > silently fail if they try to do device assignment. There's > > > probably no reason to build this file if > > > KVM_CAP_DEVICE_ASSIGNMENT isn't defined (see how the in-kernel > > > PIT gets conditionally build depending on whether that cap is > > > available). > > > > Ok, I'll take a look at this. > > I reworked it per your suggestion so that device assignment is a kvm > only feature for now. I am pretty sure Amit intended for the patches > to support device assignment without kvm too, but getting rid of it > did make things simpler.
By the way, one thing I ran into here is that we check the PIT and DEVICE_ASSIGNMENT capabilities based on the kernel headers under kernel/ first, and sync the kernel headers from the patched kernel tree into kernel/ second. In other words, if you configure userspace with a patched kernel tree and just edit include/linux/kvm.h to have or not have the capability, the build will use the old copy of the header first, and only pick up the new copy later after it resynch's the header. Seems rather counter-intuitive. Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ <-> SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
