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 dom0

To: "Allen M Kay" <allen.m.kay@xxxxxxxxx>
Subject: RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0 screen
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 04 Oct 2010 16:24:01 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Weidong Han <weidong.han@xxxxxxxxx>, Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jean Guyader <jean.guyader@xxxxxxxxx>
Delivery-date: Mon, 04 Oct 2010 08:26:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <987664A83D2D224EAE907B061CE93D530160643BAC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <987664A83D2D224EAE907B061CE93D530160643BAC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 04.10.10 at 17:11, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:
>>  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.

Yes, and vendor/class check would seem reasonable here.

> 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.

I would have thought doing it the other way around (looking for
a matching device [e.g. vendor:class] at all potential bus:dev.fn
tuples). Doesn't Linux get away without hardcoded numbers?

>>>+    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.

Perhaps I didn't say clearly enough what I mean: I'd want the first
if()'s constituents changed (i.e. to

    if ( is_igd_drhd(drhd) && !is_igd_vt_enabled() )

) so that the easy test gets executed first, and the PCI config
space access is avoided as much as possible. This would be less
of an issue if you knew that the device you're trying to read
from is actually an IGD.


Xen-devel mailing list