Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
> Sander Eikelenboom wrote:
>> Hello Weidong,
>>
>> Wouldn't it be more clear to add an option to iommu= for this case ?
>>
>> if iommu=on,..,..,security
>>
>> With the security option specified:
>>      -it would be most strict in it's checks, since enforcing security with 
>> the iommu requires that as you have pointed out.
>>      -warn,fail or panic incase it can't enable all to enforce the security.
>>   
> iommu=force is for security. It does as you described above. So I think  
> "security" option is not necessary.
>> Without the security option specified (default)
>>      - it tries to work as with the security option specified
>>      - but incase of problems makes the assumption the iommu's main task is 
>> not security, but making as much of vt-d working to keep the passthrough 
>> functionality
>>      - it will only warn, that you will lose the security part, that it 
>> would be wise to let your bios be fixed, and not making it panic
>>      - and keep vt-d enabled
>>
>>   
> the default iommu=1 works like iommu=force if BIOS is correct. But in  
> fact we encountered some buggy BIOS, and then we added some workarounds  
> to make VT-d still be enabled,  or warn and disable VT-d if the issue is  
> regarded as invalid and cannot be workarounded. These workarounds make  
> Xen more defensive to VT-d BIOS issues. The panic only occurs when  
> operating VT-d hardware fails, because it means the hardware is possibly  
> malfunctional.
>
> In short, default iommu=1 can workaround known VT-d BIOS issues we  
> observed till now, while iommu=force ensures best security provided by 
> VT-d.
>

So the default iommu=1 might be insecure? And iommu=force is always secure? 

To me "force" sounds like it makes it work always, no matter if it's secure or 
not..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel