WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking

To: Weidong Han <weidong.han@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Wed, 10 Mar 2010 19:32:01 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, "linux@xxxxxxxxxxxxxx" <linux@xxxxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 10 Mar 2010 18:32:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B985150.1000001@xxxxxxxxx>
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>
References: <C77E162B.6FE6%keir.fraser@xxxxxxxxxxxxx> <4B59098B.6000108@xxxxxxxxx> <4B590FA4.4000008@xxxxxxxxxxxxxx> <4B59132B.40607@xxxxxxxxx> <4B59188C.50901@xxxxxxxxxxxxxx> <4B59660F.4000909@xxxxxxxxx> <7162ab21003091339i4adb8669safd5e074607386a2@xxxxxxxxxxxxxx> <4B9706B3.3050903@xxxxxxxxx> <1268191101.3015.30.camel@xxxxxxxxxx> <4B9711CF.7030908@xxxxxxxxx> <1268192253.3015.37.camel@xxxxxxxxxx> <4B971F57.9000903@xxxxxxxxx> <1268196438.3015.56.camel@xxxxxxxxxx> <4B974438.3050806@xxxxxxxxx> <1268229408.14039.151.camel@xxxxxxxxxx> <1268244414.14039.206.camel@xxxxxxxxxx> <4B985150.1000001@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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,

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
> 




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel