Re: iommu=dom0-passthrough behavior

["Jan Beulich" <JBeulich@suse.com>]

>>> On 13.11.12 at 12:13, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> Jan Beulich wrote on 2012-11-13:
>>>>> On 13.11.12 at 09:50, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:
>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>>> Bottom line - I'm seeking advice as to whether working around this problem
>>>> in the IOMMU code is desirable/necessary, or whether this is a design flaw
>>>> on the device's side that just cannot be tolerated with an IOMMU in the
>>>> picture (which would need good reasoning, so that a customer expecting
>>>> such a device to work regardless of IOMMU usage can understand that this
>>>> cannot reasonably be made work).
> 
> Why not just disable the IOMMU in this case ?

Because that disables (secure) pass through of other devices.

>>> The issue is why the non-zero functions don't claim themselves during PCI bus
>>> scan.
>> 
>> As said - I can't tell whether there is a secondary function in the
>> first place (and I didn't try to find out because it doesn't really
>> matter for the purpose of finding a solution/workaround).
> 
> If software cannot see it, then how to use it? If there still have an 
> approach to detect it, then xen can do it too and setup the context entry as 
> passthrough.

We see it the latest at the point the fault occurs. So there are
multiple options:
a) if the device is "real" as in having a valid config space despite
    func 0 not advertising itself as multi-function, we have ways to
    discover the device (at boot time)
b) we could insert the context entry in the fault handler, assuming
    the device is able to recover
c) we could provide a command line option to allow fake devices to
    be created
d) we could create context entries for all BDFs, whether or not a
    device exists there
Does any of these have obvious downsides?

Jan