|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options)
Hello Stephen,
Although I think this is an enrichment for the wiki docs, the pdf doesn't
contain what i meant :-)
This pdf document gives (all) options to specify for xen guests.
What i was wondering about was all the options that i could:
- pass to the hypervisor on boot.
- for example dom0_mem=xxx or serial console settings, iommu/vt-d options,
xen powermanagement options, debug options like "cpufreq.debug=2" etc.
- as well as the xen-specific/related options one could give to the dom0 linux
kernel (for both the 2.6.18.8 branch as well as jeremy's pvops).
- for example console options that would work with serial console, pciback,
reassign_resources, guestdev etc.
I don't know if you also have any starting document about this as well ?
Perhaps other wiki's about specific subjects could point to such a list for the
latest and greatest in related boot options as well.
If there isn't such document i would like to help and try to contribute such a
list.
--
Regards
Sander
Monday, January 25, 2010, 5:40:53 PM, you wrote:
> Team:
> The document in question is located at
> http://www.xen.org/files/Support/XenConfigurationDetails.pdf. I am going to
> move the document into the Xen Wiki this morning and will have the final
> version at http://wiki.xensource.com/xenwiki/XenConfigurationFileOptions.
> Thanks.
> ...spector
> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@xxxxxx]
> Sent: Saturday, January 23, 2010 9:55 AM
> To: Sander Eikelenboom
> Cc: Weidong Han; xen-devel@xxxxxxxxxxxxxxxxxxx; Kay, Allen M; Cihula, Joseph;
> Noboru Iwamatsu; Keir Fraser; Stephen Spector
> 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@xxxxxxxxxxxxxx
>>
--
Best regards,
Sander mailto:linux@xxxxxxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |