Re: [Xen-devel] xen 3.3.0 pv pci passthrough co-assigned problem

[Stefan Neuwirth <stefan-neuwirth@xxxxxxxxxxx>]

Hi Dexuan,

"Cui, Dexuan" <dexuan.cui@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel