Re: PCI Passthru: fn0 exported but not fn1

[Jambunathan K <jambunathan@netxen.com>]

Keir Fraser wrote:
> Why did you not use VPCI? Does that not work for you? It should avoid the
> problem that is currently blocking your progress.
> 
>  -- Keir
> 
> 
> On 24/8/07 15:58, "Jambunathan K" <jambunathan@netxen.com> wrote:
> 
>> CONFIG_XEN_PCIDEV_FRONTEND=y
>> CONFIG_XEN_PCIDEV_FE_DEBUG=y
>> CONFIG_XEN_PCIDEV_BACKEND=y
>> # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
>> CONFIG_XEN_PCIDEV_BACKEND_PASS=y
>> # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
>> CONFIG_XEN_PCIDEV_BE_DEBUG=y
>>
>> I have overridden default VPCI with explicit BACKEND_PASS. Both Dom0 and
>> Dom1 run the same kernel binary.
>>
>> I had used the above configuration all along (on both Xen304 + Xen310)
>> and have seen fn1 exported 'as such' to Dom1. It is with my new box that
>> I have the above issue.
> 
> 
> 

I did some more experiments and here is what I find.

I) In PASS mode,
	a) Guest domain *cannot* see fn2 if *only* fn2 is exported.
	b) Guest domain *can* see fn2 *only if* fn0 is also exported to it.

II) In VPCI mode,
	a) Guest domain *cannot* see fn2 if *only* fn2 is exported.
	b) Guest domain *can* see fn2 *only if* fn0 is also exported to it.

III) In SLOT mode,
	a) Guest doamin can see fn2 even if *only* fn2 is exported.


A cursory look suggests that the difference in behaviour is due to the
way pcifront scans devices. It scans non-zero fns only if it actually
sees a device at *fn0*.

Our device requires that the fn-no be preserved as such (even if other
PCI params change) for proper working.

I am trying to export 4 PCI functions in our device to 4 different
domains. I am stuck at not being able to use *any* of the passthrough
methods.

If behaviours (I) and (II) above is as intended may I know why this is
so?. If not, would you agree that this is a bug?

Jambunathan K.