Stephen Spector
2010-Jan-23 16:20 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options
Makes sense. Will move files on monday. Thanks ----- Original Message ----- From: Pasi Kärkkäinen <pasik@iki.fi> To: Sander Eikelenboom <linux@eikelenboom.it> Cc: Weidong Han <weidong.han@intel.com>; xen-devel@lists.xensource.com <xen-devel@lists.xensource.com>; Kay, Allen M <allen.m.kay@intel.com>; Cihula, Joseph <joseph.cihula@intel.com>; Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>; Keir Fraser; Stephen Spector Sent: Sat Jan 23 09:54:35 2010 Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options 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@eikelenboom.it >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel