[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Sat, Jan 23, 2010 at 08:40:10PM +0800, Weidong Han wrote:
> Pasi Kärkkäinen wrote:
>> 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..
>>   
> The "security" here means the protection provided VT-d. The main  
> difference between them is iommu=force tries to enable all VT-d units in  
> any case, if any VT-d unit cannot enabled, it will quit Xen booting  
> (panic), thus it guarantees security provided by VT-d. while when  
> iommu=1, in order to workaround some BIOS issues, it will ignore some  
> invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d. 
>

Ok.. Thanks for explaining it. 

-- Pasi


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.