Re: iommu=dom0-passthrough behavior

["Zhang, Yang Z" <yang.z.zhang@intel.com>]

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

Why not just disable the IOMMU in this case ?

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

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


Best regards,
Yang