Xen devel - Oct 2008 - xen 3.3.0 pv pci passthrough co-assigned problem

After
upgrading from xen 3.2.x to xen 3.3.0 I get an error message
when
using pci passthrough with pv guests (my system is not vt-d
enabled):

xm create -c /etc/xen/domU/myguest
Using
config file "/etc/xen/domU/myguest".
Error: pci:
0000:0e:05.0 must be co-assigned to the same guest with 0000:0f:0a.0

Sharing diffrent pci devices behind a pci bridge used to work in
older
xen versions for pv guests. It seems the restriction for the
vt-d
passthrough is also applied to the pv passthrough - any reason
for
this? For me this is a real big regression.

Stefan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Stefan,
I think you mean you don't specify the "iommu" parameter at all in
Xen grub entry (so VT-d is not turned on by default) and then you try to create
a PV guest with "pci=['xx:xx.x']" specified in the PV guest
config file and you meet with the "co-assignment issue". Correct?

I didn't test the traditional PV-only PCI passthrough.
We only specify a string "pci=['xx:xx.x']" in pv guest config
file. How can Xend tell whether we're using the traditional PCI passthrough
or the VT-d passthrough? Judging by the "iommu=pv or no-pv" xen
parameter? I'm not sure about that for now...

Thanks,
-- Dexuan
________________________________

From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
stefan-neuwirth@t-online.de
Sent: 2008年10月16日 15:20
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen 3.3.0 pv pci passthrough co-assigned problem


After upgrading from xen 3.2.x to xen 3.3.0 I get an error message
when using pci passthrough with pv guests (my system is not vt-d
enabled):

xm create -c /etc/xen/domU/myguest
Using config file "/etc/xen/domU/myguest".
Error: pci: 0000:0e:05.0 must be co-assigned to the same guest with 0000:0f:0a.0

Sharing diffrent pci devices behind a pci bridge used to work in older
xen versions for pv guests. It seems the restriction for the vt-d
passthrough is also applied to the pv passthrough - any reason for
this? For me this is a real big regression.

  Stefan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Dexuan,

"Cui, Dexuan" <dexuan.cui@intel.com> writes:
> Hi Stefan, I think you mean you don''t specify the
"iommu" parameter
> at all in Xen grub entry (so VT-d is not turned on by default) and
> then you try to create a PV guest with
"pci=[''xx:xx.x'']" specified
> in the PV guest config file and you meet with the "co-assignment
> issue". Correct?
yes. I fact xen tells me vt-d is disabled:

...
(XEN) Brought up 8 CPUs
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
...
> I didn''t test the traditional PV-only PCI passthrough.  We only
> specify a string "pci=[''xx:xx.x'']" in pv guest
config file. How can
> Xend tell whether we''re using the traditional PCI passthrough or
the
> VT-d passthrough? Judging by the "iommu=pv or no-pv" xen
parameter?
> I''m not sure about that for now...
No, I don''t think the xen iommu parameter is the right flag to judge
this. For example I can think of a setup where I wan''t to run PV and
HVM guests on the same dom0, both using PCI passthrough.

Doesn''t the xend know if he starts a PV or a HVM guest? For example
the option ''builder'' or ''kernel'' in the
guest''s config file should
tell him. This assumes that vt-d passthrough is not possible with
traditional PV - is it?

Another way would be the use of traditional PCI passthrough if vt-d is
disabled.

And last but not least let the user/admin do the choice by an new
parameter in the config file of the guest. In fact I''m using PCI
passthrough to divide subfunctions of a single pci board to diffrent
guests (e.g. quad ethernet card).

Is there a quick hack to get back the old behaviour for now?

  Stefan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>> I didn''t test the traditional PV-only PCI passthrough.  We
only
>> specify a string "pci=[''xx:xx.x'']" in pv
guest config file. How can
>> Xend tell whether we''re using the traditional PCI passthrough
or the
>> VT-d passthrough? Judging by the "iommu=pv or no-pv" xen
parameter?
>> I''m not sure about that for now...
>
> No, I don''t think the xen iommu parameter is the right flag to
judge
> this. For example I can think of a setup where I wan''t to run PV
and
> HVM guests on the same dom0, both using PCI passthrough.
I think HVM geust can''t use the traditional PCI passthrough; HVM guest
can only use the VT-d/IOMMU passthrough.
>
> Doesn''t the xend know if he starts a PV or a HVM guest? For
example
> the option ''builder'' or ''kernel'' in the
guest''s config file should
> tell him. This assumes that vt-d passthrough is not possible with
> traditional PV - is it?
>
> Another way would be the use of traditional PCI passthrough if vt-d is
> disabled.
>
> And last but not least let the user/admin do the choice by an new
> parameter in the config file of the guest.
Yes. I think we should consider this.
> In fact I''m using PCI
> passthrough to divide subfunctions of a single pci board to diffrent
> guests (e.g. quad ethernet card).
>
> Is there a quick hack to get back the old behaviour for now?
>
Can you try applying the attached patch to your /usr/lib64/python/xen/ ?
Hope this can work for you at present.

Thanks,
-- Dexuan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel