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