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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Hmm perhaps somewhat unrelated, but is there a comprehensive list with Xen 
specific boot options with explanation ?

Since some seem to be valid for 2.6.18.8 some for pvops as well, and the 
hypervisor has some of her own.
If not I could perhaps try to make a Wiki with a table with options and 
explanation for it ?

This discussion seems to show sometimes you can interpret some option names in 
multiple ways and things have additional consequences.

--
Sander


Saturday, January 23, 2010, 2:08:50 PM, you wrote:

> 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




-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


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