[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] intel IGD driver intel_detect_pch() failure



I dug further and got confused.
The host ISA bridge 00:1f.0 is automatically passed-through as part of the gfx_passthru magic.
However, it is passed through as a PCI bridge:
On host:   00:1f.0 ISA bridge [0601]: Intel Corporation H77 Express Chipset LPC Controller [8086:1e4a] (rev 04)
On guest: 00:1f.0 PCI bridge [0604]: Intel Corporation H77 Express Chipset LPC Controller [8086:1e4a] (rev 04)

This is both the case for pure HVM && PVHVM. And this one exists for both case too:
00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000]

And the intel_detect_pch() function only check the first ISA bridge on the PCI bus:
pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL);

Unless there are magic elsewhere, I can't imagine the code would behave differently on the two builds.
But what's the magic behind this?

Also, is there anyway to get rid of the ISA bridge emulated by qemu?
I don't think this is ever required for most case...

Thanks,
Timothy


On Sun, Dec 9, 2012 at 1:43 AM, G.R. <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:

Hi all,
I'm debugging an issue that an HVM guest failed to produce any output with IGD passed through.
This is an pure HVM linux guest with i915 driver directly compiled in.
An PVHVM kernel with i915 driver compiled as module works without issue.
I'm not yet sure which factor is more important, pure HVM or the I915=y kernel config.

The direct cause of no output is that the driver does not select Display PLL properly, which is in turn due to fail to detect pch type properly.

Strange enough, the intel_detect_pch() function works by checking the device ID of the ISA bridge coming with the chipset:

/* * The reason to probe ISA bridge instead of Dev31:Fun0 is to * make graphics device passthrough fwork easy for VMM, that only * need to expose ISA bridge to let driver know the real hardware  underneath. This is a requirement from virtualization team. */

I added some debug output in this function and find out that it obtained a strange device ID:
[ 1.005423] [drm] intel pch detect, found 00007000

This looks like the ISA bridge provided by qemu:
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.0 0601: 8086:7000

However, I can find the same device on a PVHVM linux guest, but the intel_detect_pch() is not fooled by that. Is it due to I915=m config or some magic played by PVOPS? Any suggestion how to fix this?

Thanks,
Timothy


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.