[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.