From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: [PATCH] VT-d: improve RMRR validity checking Date: Tue, 26 Jan 2010 14:42:47 +0800 Message-ID: <4B5E8EE7.3010104@intel.com> References: <4B5DA659.1030506@intel.com> <4B5E4276.90308@jp.fujitsu.com> <4B5E82D1.8060206@intel.com> <4B5E8DF0.507@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B5E8DF0.507@jp.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Noboru Iwamatsu Cc: "linux@eikelenboom.it" , "Cihula, Joseph" , "xen-devel@lists.xensource.com" , "Kay, Allen M" , "keir.fraser@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org Noboru Iwamatsu wrote: > Hi Weidong, > > >> I implemented a patch for it. Noboru, pls have a try on your machine. >> If you use default iommu=1, VT-d will be disabled with warning messages. >> If you use iommu=workaround_bios_bug, it should enable VT-d and works >> for you. >> If you use iommu=force, it panics. >> > > On my machine, each options have worked as described. > Thanks Noboru. > I tried: > xen-unstable c/s 20844 + drhd-ignore.patch + workaround-bios.patch > drhd-ignore.patch was already checked in as c/s 20846. Keir, pls check in the workaround-bios.patch. Thanks. Regards, Weidong > Thanks, > Noboru. > > >> patch title: VT-d: add "iommu=workaround_bios_bug" option >> patch description: >> Add this option to workaround BIOS bugs. Currently it ignores DRHD if >> "all" devices under its scope are not pci discoverable. This workarounds >> a BIOS bug in some platforms to make VT-d work. But note that this >> option doesn't guarantee security, because it might ignore DRHD. >> So there are 3 options which handle BIOS bugs differently: >> iommu=1 (default): If detect non-existent device under a DRHD's scope, >> or find incorrect RMRR setting (base_address > end_address), disable >> VT-d completely in Xen with warning messages. This guarantees security >> when VT-d enabled, or just disable VT-d to let Xen work without VT-d. >> iommu=force: it enforces to enable VT-d in Xen. If VT-d cannot be >> enabled, it will crashes Xen. This is mainly for users who must need VT-d. >> iommu=workaround_bogus_bios: it workarounds some BIOS bugs to make VT-d >> still work. This might be insecure because there might be a device not >> protected by any DRHD if the device is re-enabled by malicious s/w. This >> is for users who want to use VT-d regardless of security. >> >> Signed-off-by: Weidong Han >> >> Regards, >> Weidong >> >> Noboru Iwamatsu wrote: >> >>> Weidong, Keir, >>> >>> I agree your suggestions. >>> >>> Noboru. >>> >>> >>>> Keir Fraser wrote: >>>> >>>>> On 25/01/2010 10:45, "Sander Eikelenboom" wrote: >>>>> >>>>> >>>>>> a) Could be discussed if panic should be default instead of disabling >>>>>> iommu or >>>>>> not, although there seem to be a lot of broken bioses, so that would >>>>>> lead to a >>>>>> lot of machines not booting. >>>>>> >>>>> Absolutely not acceptable. Warn and completely disable IOMMU is the >>>>> correct >>>>> default causing least pain to the most end users. >>>>> >>>>> -- Keir >>>>> >>>>> >>>> Agree. It should not crash Xen by default due to BIOS issues. >>>> warn-and-disable is better. It won't impact common Xen users, and if a >>>> user really wants to use VT-d, he can try iommu=workaround_bogus_bios, >>>> or directly report to OEM vendor to get it fixed in BIOS. As VT-d is >>>> used more and more widely, I think the BIOS issues will be found and >>>> fixed more quickly than before, thus the situation should be better. >>>> >>>> Regards, >>>> Weidong >>>> >>>> >>>> >>>> >>> > > >