HVM driver domains do not appear to be usable with stubdomains

HVM driver domains do not appear to be usable with stubdomains

[Chris Brannon]

Hi,
I set up a network driver domain for a dom0; it uses HVM
virtualization.  It worked very well when not using a device model
stubdomain, but when I requested the use of a device model stubdomain in
my xl.cfg file, the domU refused to boot.  It gave the following error
message.

[76594.195404] xen_pciback: vpci: 0000:05:00.0: assign to virtual slot 0
[76594.195927] pciback 0000:05:00.0: registering for 35
[76594.230592] xen-pciback pci-34-0: 22 Couldn't locate PCI device
    (0000:05:00.0)! perhaps already in-use?

It seems to me that Xen is trying to pass the PCI device to both the
domU and the stubdomain, and that is why it is failing.  Has anyone
managed to get an HVM driver domain running with a stubdomain?  If so,
how did you do it?  Or is it expected that HVM driver domains won't work
with stubdomains?

-- Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: HVM driver domains do not appear to be usable with stubdomains

[Christopher Clark]

On Tue, Dec 4, 2018 at 10:11 AM Chris Brannon <cmb@prgmr.com> wrote:
>
> Hi,
> I set up a network driver domain for a dom0; it uses HVM
> virtualization.  It worked very well when not using a device model
> stubdomain, but when I requested the use of a device model stubdomain in
> my xl.cfg file, the domU refused to boot.  It gave the following error
> message.
>
> [76594.195404] xen_pciback: vpci: 0000:05:00.0: assign to virtual slot 0
> [76594.195927] pciback 0000:05:00.0: registering for 35
> [76594.230592] xen-pciback pci-34-0: 22 Couldn't locate PCI device
>     (0000:05:00.0)! perhaps already in-use?
>
> It seems to me that Xen is trying to pass the PCI device to both the
> domU and the stubdomain, and that is why it is failing.  Has anyone
> managed to get an HVM driver domain running with a stubdomain?  If so,
> how did you do it?  Or is it expected that HVM driver domains won't work
> with stubdomains?

OpenXT uses a HVM driver domain with a stubdomain for the network
device driver, using Linux stubdomains with code very similar to that
Marek has posted on this list.

These pull requests may be a good place to start looking.
https://github.com/OpenXT/openxt/pull/311
and
https://github.com/OpenXT/xenclient-oe/pull/912
which includes this patch to qemu (originally from Qubes, referencing:
https://github.com/QubesOS/qubes-issues/issues/2849) -:
https://github.com/OpenXT/xenclient-oe/pull/912/files#diff-14774cbc013c07a1e7409b0db1cc3359

Christopher

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: HVM driver domains do not appear to be usable with stubdomains

[Chris Brannon]

Christopher Clark <christopher.w.clark@gmail.com> writes:

> On Tue, Dec 4, 2018 at 10:11 AM Chris Brannon <cmb@prgmr.com> wrote:
>>
>> Hi,
>> I set up a network driver domain for a dom0; it uses HVM
>> virtualization.  It worked very well when not using a device model
>> stubdomain, but when I requested the use of a device model stubdomain in
>> my xl.cfg file, the domU refused to boot.  It gave the following error
>> message.
>>
>> [76594.195404] xen_pciback: vpci: 0000:05:00.0: assign to virtual slot 0
>> [76594.195927] pciback 0000:05:00.0: registering for 35
>> [76594.230592] xen-pciback pci-34-0: 22 Couldn't locate PCI device
>>     (0000:05:00.0)! perhaps already in-use?
>>
>> It seems to me that Xen is trying to pass the PCI device to both the
>> domU and the stubdomain, and that is why it is failing.  Has anyone
>> managed to get an HVM driver domain running with a stubdomain?  If so,
>> how did you do it?  Or is it expected that HVM driver domains won't work
>> with stubdomains?
>
> OpenXT uses a HVM driver domain with a stubdomain for the network
> device driver, using Linux stubdomains with code very similar to that
> Marek has posted on this list.
>
> These pull requests may be a good place to start looking.
> https://github.com/OpenXT/openxt/pull/311
> and
> https://github.com/OpenXT/xenclient-oe/pull/912
> which includes this patch to qemu (originally from Qubes, referencing:

Hi Christopher,
Thank you for the pointers.  That gives me a very good place to start.
So if I understand correctly, the problem is that PCI passthrough
doesn't work with stubdomains, unless qemu is patched?

-- Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: HVM driver domains do not appear to be usable with stubdomains

[Jason Andryuk]

On Tue, Dec 11, 2018 at 1:18 PM Chris Brannon <cmb@prgmr.com> wrote:
>
> Christopher Clark <christopher.w.clark@gmail.com> writes:
>
> > On Tue, Dec 4, 2018 at 10:11 AM Chris Brannon <cmb@prgmr.com> wrote:
> >>
> >> Hi,
> >> I set up a network driver domain for a dom0; it uses HVM
> >> virtualization.  It worked very well when not using a device model
> >> stubdomain, but when I requested the use of a device model stubdomain in
> >> my xl.cfg file, the domU refused to boot.  It gave the following error
> >> message.
> >>
> >> [76594.195404] xen_pciback: vpci: 0000:05:00.0: assign to virtual slot 0
> >> [76594.195927] pciback 0000:05:00.0: registering for 35
> >> [76594.230592] xen-pciback pci-34-0: 22 Couldn't locate PCI device
> >>     (0000:05:00.0)! perhaps already in-use?
> >>
> >> It seems to me that Xen is trying to pass the PCI device to both the
> >> domU and the stubdomain, and that is why it is failing.  Has anyone
> >> managed to get an HVM driver domain running with a stubdomain?  If so,
> >> how did you do it?  Or is it expected that HVM driver domains won't work
> >> with stubdomains?
> >
> > OpenXT uses a HVM driver domain with a stubdomain for the network
> > device driver, using Linux stubdomains with code very similar to that
> > Marek has posted on this list.
> >
> > These pull requests may be a good place to start looking.
> > https://github.com/OpenXT/openxt/pull/311
> > and
> > https://github.com/OpenXT/xenclient-oe/pull/912
> > which includes this patch to qemu (originally from Qubes, referencing:
>
> Hi Christopher,
> Thank you for the pointers.  That gives me a very good place to start.
> So if I understand correctly, the problem is that PCI passthrough
> doesn't work with stubdomains, unless qemu is patched?

Hi, Chris.

I pulled in the QEMU patch because I found that my Intel wired
ethernet device didn't work without it.  I believe my Intel wireless
NIC did though.  Maybe it was the opposite... I should have documented
it more.  However the device was passed-through - it just wasn't
operational.

What device is 0000:05:00.0?  Is it listed by `xl pci-assignable-list`?

Regards,
Jason

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: HVM driver domains do not appear to be usable with stubdomains

[Chris Brannon]

Jason Andryuk <jandryuk@gmail.com> writes:

>> So if I understand correctly, the problem is that PCI passthrough
>> doesn't work with stubdomains, unless qemu is patched?
>
> Hi, Chris.
>
> I pulled in the QEMU patch because I found that my Intel wired
> ethernet device didn't work without it.  I believe my Intel wireless
> NIC did though.  Maybe it was the opposite... I should have documented
> it more.  However the device was passed-through - it just wasn't
> operational.
>
> What device is 0000:05:00.0?  Is it listed by `xl pci-assignable-list`?

Hi Jason,
0000:05:00.0 was an Intel wired ethernet device.  Yes it showed up
in xl pci-assignable-list.  In fact, my driver domain worked fine without
a stubdomain; the card was passed through and I had it passing traffic
with no problem at all.

-- Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel