2010/6/4 Jim Fehlig <jfehlig@xxxxxxxxxx>: > Matthias Bolte wrote: >> >> This blog post [1] explains how to apply some OpenSuse patches [2] >> (especially xen-domctl-ver7.patch) > > Ah yes, reminds me to upstream this patch. We had all of the cpu pools > patches (which changed domctl interface) in Xen4.0 in openSUSE build > service. These patches were not included in official Xen4.0 release but > have since been included in xen-unstable. In order to use the Xen in OBS, I > needed to patch libvirt to handle domctl version 7. Now that the cpu pools > patches have been taken in xen-unstable it's time to upstream the libvirt > patch as well. > >> to the libvirt 0.8.1 Debian package >> in order to get Xen 4.0 support. >> > > Xen4.0 doesn't contain the cpu pools feature, which changes the domctl > interface. I guess they are using xen-unstable, or perhaps have Fujitsu's > cpu pools patches as well? > > Thanks, > Jim > As I understood his problem Xen 4.0 basically works with a libvirt 0.8.1 version patched as described in the blog post. The actual problem is PCI passthrough, because Xen 4.0 added new required parameters like the key parameter. With the quick fix of hardcoding key to 0x0, he was able to define the domain, but starting the domain failed with XenD complaining about a missing vdevfn parameter. Looking at the commit history suggest that the vslot parameter was just renamed to vdevfn. But libvirt never used the vslot parameter before, and now it seems to be mandatory. I assisted him in debugging and used the Xen 4.0 tarball [1] as basis to look at the code. I think that's the stable version. Therefore, I think this PCI passthrough problem is not related to "CPU pools". Matthias [1] http://www.xen.org/products/xen_source.html -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list