Re: iommu=dom0-passthrough behavior

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

>>> On 13.11.12 at 09:50, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> We need to settle on the concept here first: What specifically is said 
>> option intended to do? 
> 
> Basically,  this options just allows the transactions from dom0's devices 
> not subject to VT-d engine.  Actually,  It is not targeted to fix something, 
> but just allows users isolating VT-d issues from dom0. 
> As I know, in early days, VT-d is not that stable,   if dom0's devices are 
> controlled by VT-d,  some strange issues may trigger in system's boot stage, 
> so use this options to disable VT-d for Dom0. 

Which it doesn't, as the specific case here shows.

>> 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).
> 
> 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).

>   From security point of view,  VT-d shouldn't allow transactions from 
> the unknown devices. 

That's inconsistent with what you say above: Either there is a way
to suppress IOMMU involvement in Dom0 operation (which is
inherently insecure), or there is not. If there is, there's no point in
claiming security for one aspect but not another.

I think it is obvious that I'm not suggesting to allow pass through of
such a device at this point (albeit even that would seem possible and,
from a customer's pov, desirable), and as long as users are aware of
the security implications when using the option under discussion here,
I don't see why that option shouldn't be made fully work. It should be
left to the admins of individual systems to decide between security
and functionality, we should provide them with ways to implement
their choice.

Otoh I'm unaware of a similar option for native Linux, yet it is
suffering the same problem on that system when DMA translation
gets turned on.

But the direction you give to the discussion doesn't lead us towards
a solution for the customer (or a profound explanation why none
is possible), so if we could please focus on that aspect again.

Jan