From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: [PATCH] VT-d: improve RMRR validity checking Date: Thu, 11 Mar 2010 11:44:54 +0800 Message-ID: <4B986736.9000204@intel.com> References: <4B59098B.6000108@intel.com> <4B590FA4.4000008@jp.fujitsu.com> <4B59132B.40607@intel.com> <4B59188C.50901@jp.fujitsu.com> <4B59660F.4000909@intel.com> <7162ab21003091339i4adb8669safd5e074607386a2@mail.gmail.com> <4B9706B3.3050903@intel.com> <1268191101.3015.30.camel@2710p.home> <4B9711CF.7030908@intel.com> <1268192253.3015.37.camel@2710p.home> <4B971F57.9000903@intel.com> <1268196438.3015.56.camel@2710p.home> <4B974438.3050806@intel.com> <1268229408.14039.151.camel@8530w.home> <1268244414.14039.206.camel@8530w.home> <4B985150.1000001@intel.com> <1268274721.3015.64.camel@2710p.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1268274721.3015.64.camel@2710p.home> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Alex Williamson Cc: "xen-devel@lists.xensource.com" , Noboru Iwamatsu , "Cihula, Joseph" , "Kay, Allen M" , "linux@eikelenboom.it" , "keir.fraser@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org Alex Williamson wrote: > On Thu, 2010-03-11 at 10:11 +0800, Weidong Han wrote: > > >> Alex, you are right. IOAPICs can be included in any DRHDs. Pls try >> following patch, if no problem, I will submit it. >> > > Thanks Weidong. This of course works, but I still get this output: > > (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 > (XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec08000, GSI 24-47 > (XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec10000, GSI 48-71 > (XEN) Enabling APIC mode: Phys. Using 3 I/O APICs > (XEN) [VT-D]dmar.c:421: Non-existent device (84:13.0) is reported in this DRHD's scope! > (XEN) [VT-D]dmar.c:442: There are devices under device scope are not PCI discoverable! if xen fails at VT-d enabling, pls try option iommu=workaround_bios_bug. > > So now we've effectively relegated this code to printing things that > look like errors for both actual bad DMAR tables and 100% spec compliant > tables. At a minimum, I think these dprintks need to be reduce to info > or debug level since they're effectively just spewing out noise. Can't > we put a tag for the device type in the list of scope devices and skip > checking discoverable PCI devices for IOAPICs? Do we need to do the > same for HPETs? Thanks, > good suggestion to check the device type. I cooked a new patch. It skips checking IOAPIC and HPET. pls have a try. diff -r cadf1bae9ee2 xen/drivers/passthrough/vtd/dmar.c --- a/xen/drivers/passthrough/vtd/dmar.c Thu Feb 25 18:26:45 2010 +0800 +++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 11 19:39:45 2010 +0800 @@ -407,9 +407,15 @@ acpi_parse_one_drhd(struct acpi_dmar_ent { u8 b, d, f; int i, invalid_cnt = 0; + struct acpi_dev_scope *acpi_scope = dev_scope_start; for ( i = 0; i < dmaru->scope.devices_cnt; i++ ) { + acpi_scope += (i == 0) ? 0 : acpi_scope->length; + if ( acpi_scope->dev_type == ACPI_DEV_IOAPIC || + acpi_scope->dev_type == ACPI_DEV_MSI_HPET ) + continue; + b = PCI_BUS(dmaru->scope.devices[i]); d = PCI_SLOT(dmaru->scope.devices[i]); f = PCI_FUNC(dmaru->scope.devices[i]); > Alex > > > >> diff -r cadf1bae9ee2 xen/drivers/passthrough/vtd/dmar.c >> --- a/xen/drivers/passthrough/vtd/dmar.c Thu Feb 25 18:26:45 2010 +0800 >> +++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 11 17:49:40 2010 +0800 >> @@ -437,11 +437,9 @@ acpi_parse_one_drhd(struct acpi_dmar_ent >> else >> { >> dprintk(XENLOG_WARNING VTDPREFIX, >> - " The DRHD is invalid due to there are devices under " >> - "its scope are not PCI discoverable! Pls try option " >> - "iommu=force or iommu=workaround_bios_bug if you " >> - "really want VT-d\n"); >> - ret = -EINVAL; >> + " There are devices under device scope are not PCI " >> + "discoverable! if xen fails at VT-d enabling, pls try " >> + "option iommu=workaround_bios_bug.\n"); >> } >> } >> else >> >> > > > >