From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: [PATCH] VT-d: improve RMRR validity checking Date: Thu, 21 Jan 2010 18:03:15 +0800 Message-ID: <4B582663.5030008@intel.com> References: <60E426D47DE8EA47AA104E65008A100D14458756F3@shzsmsx501.ccr.corp.intel.com> <4B580F8C.5090807@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: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Lyon Cc: "xen-devel@lists.xensource.com" , Noboru Iwamatsu List-Id: xen-devel@lists.xenproject.org Andrew Lyon wrote: > On Thu, Jan 21, 2010 at 8:25 AM, Noboru Iwamatsu > wrote: > >> Hi, >> >> Some Q35 mainboard that has buggy BIOS, I have one of this, >> reports invalid DRHD in addition to the invalid RMRR. >> >> Attached patch fixes this DRHD issue in the same way as RMRR. >> And also, I fixed RMRR validity checking loop. >> >> Noboru. >> >> Signed-off-by: Noboru Iwamatsu >> >> >> -------- Original Message -------- >> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking >> From: Han, Weidong >> To: xen-devel@lists.xensource.com >> Date: Thu Jan 21 2010 11:46:12 GMT+0900 >> >> >>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is set >>> incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the >>> device under its scope are not pci discoverable, because the RMRR won't be >>> used by non-existed or disabled devices. >>> >>> This patch ignores the RMRR if the device under its scope are not pci >>> discoverable, and only checks the validity of RMRRs that are actually used. >>> In order to avoid duplicate pci device detection code, this patch defines a >>> function pci_device_detect for it. >>> >>> Signed-off-by: Weidong Han >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> >> > > I have a Supermicro X7DWA-N system which requires > iommu_inclusive_mapping=1 in order to boot Xen successfully with iommu > enabled, I am going to try these patches to see if the workaround is > still necessary but I would also like to ask for some help in getting > the bios fixed properly , I contacted Supermicro about this issue last > year and they said they would fix it but they wanted details of > exactly what was wrong, I tried to figure it out by using acpidump and > reading the rmrr spec but I failed to make sense of it, perhaps you > could have a quick look at this dump and let me know if there is > anything obviously wrong? > > iommu_inclusive_mapping=1 workarounds another problem. These code in Xen just makes Xen more defensive to BIOS errors. The final solution is to get them fixed in BIOS. Regards, Weidong