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