| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Problem: Pattern with vertical colored lines on the dom0
>>> 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
>>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.
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.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home