This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re:

To: Stephen Spector <stephen.spector@xxxxxxxxxx>
Subject: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options)
From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
Date: Mon, 25 Jan 2010 17:58:01 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 25 Jan 2010 08:58:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <652FFB2C8F91E3428799B1FFF8B490C9726C8E7DB2@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Eikelenboom IT services
References: <4B590FA4.4000008@xxxxxxxxxxxxxx> <4B59132B.40607@xxxxxxxxx> <4B59188C.50901@xxxxxxxxxxxxxx> <4B59660F.4000909@xxxxxxxxx> <1098023846.20100122101901@xxxxxxxxxxxxxx> <4B5996CF.9020409@xxxxxxxxx> <20100122123235.GZ2861@xxxxxxxxxxx> <4B5AEE2A.5040100@xxxxxxxxx> <20100123130850.GJ2861@xxxxxxxxxxx> <466427676.20100123153350@xxxxxxxxxxxxxx> <20100123145435.GO2861@xxxxxxxxxxx> <652FFB2C8F91E3428799B1FFF8B490C9726C8E7DB2@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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 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 




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

<Prev in Thread] Current Thread [Next in Thread>