Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options

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

On Sat, Jan 23, 2010 at 03:33:50PM +0100, Sander Eikelenboom wrote:
> 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.
> 

Have you checked this wiki page?:
http://wiki.xensource.com/xenwiki/VTdHowTo

But yeah, I think we should definitely add a wiki page
describing all the Xen + Dom0 kernel options.. a list that's up to date.

Stephen: Did you make some PDF document about Xen hypervisor boot options? 
I remember you doing PDF about the /etc/xen/<guest> cfgfile options earlier.

I think these documents should be put to a wiki page, it's much easier to update
and read them there.

-- Pasi


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