[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Xen 4.0 and DPCI key in sexpr



2010/6/4 Jim Fehlig <jfehlig novell com>:
> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]