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


RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Date: Mon, 4 Oct 2010 08:11:14 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>, Jean Guyader <jean.guyader@xxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Mon, 04 Oct 2010 08:11:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CA9AB33020000780001A522@xxxxxxxxxxxxxxxxxx>
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: <201009171520.11903.dietmar.hahn@xxxxxxxxxxxxxx> <201009241310.19462.dietmar.hahn@xxxxxxxxxxxxxx> <AANLkTin5bZdZch9y1kqUxoJHW8K4LMU5PUcuTpQLmZ0h@xxxxxxxxxxxxxx> <201009271406.26670.dietmar.hahn@xxxxxxxxxxxxxx> <20100927164706.GC4741@xxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D5301605D89C0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4CA9AB33020000780001A522@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActjnXxydqOk+XAoRpaZV7fip8bH6QANzEjw
Thread-topic: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
> The use of magic numbers (0, 2, and 0) here looks like being
> tailored to just a very limited set of systems. If it was really
> known that all current and future systems are going to have this
> arrangement, a comment saying so would be the minimum I'd
> expect.

AFAIK, 0:2.0 has been IGD device for all modern Intel systems with integrated 
graphics.  I can change to use #def.  Other than that, what are the 
alternatives to looking for 0:2.0?  Checking for vendor ID and device CLASS?  
That would preclude any possible discrete graphics from Intel.

> Also, if a check of igd against NULL or a check of type against
> DMAR_TYPE was added here, the two call sites that don't really
> need this output could simply pass NULL instead of adding a new
> local variable.

This I can do.  I'm working on a file that will consolidate all VT-d and IGD 
related quirks.  I will incorporate it.

> Similarly here (a brief comment is there, but to me this doesn't
> mean it's going to be that way forever).
> Also, if this ever needs updating, matching the magic numbers
> here and above is going to be a matter of luck. If they are to be
> hard coded, they should be #define-s, so that locating all uses
> is possible.

Unless you can offer other methods of detecting IGD, I will just change 0:2.0 
to hard coded IGD_BUS, IGD_DEV, IGD_FUNC defines as mentioned above.

>>+static void iommu_enable_translation(struct acpi_drhd_unit *drhd)
>> {
>>     u32 sts;
>>     unsigned long flags;
>>+    struct iommu *iommu = drhd->iommu;
>>+    if ( !is_igd_vt_enabled() && is_igd_drhd(drhd) )
>>+    {
>>+        if ( force_iommu )
>I would also have suggested switching the checks here: The first
>involves a PCI config space read (and even unconditional upon
>anything), while the second really just is a compare of two

I'm not sure I'm convinced you suggestion will make it clearer.  What is the 
rational for making this change?  To me current order makes more sense.  First 
set of changes checks if anything needs to be done. The second check for 
"force_iommu" decides whether to panic or disable IGD VT-d.


Xen-devel mailing list