|
|
|
|
|
|
|
|
|
|
xen-devel
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
>variables.
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.
Allen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|