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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 11 Dec 2012, G.R. wrote:
> 
> On Tue, Dec 11, 2012 at 2:15 AM, Kay, Allen M <allen.m.kay@xxxxxxxxx> wrote:
>       My understanding is that i915 driver needs to looks at the real PCH's 
> device ID to apply HW workarounds.
> 
>       One way to fix this is to make the device ID of the first PCH's 
> (00:01.0) device ID reflect the device ID of
>       00:1f.0 on the host. ÂThis way, when i915 running as a guest will find 
> the valid PCH device ID to make workaround
>       decisions with.
>
> 
>       I don't know why it would make a difference if i915 is built into the 
> kernel or as a module though.
> 
>       Allen
> 
> Thanks Allen for your input.
> But module v.s. built-in is not the only difference. Another difference is 
> the PVHVM build vs. pure HVM build.
> Both share the same PCI layout but different result. Any theory how to 
> explain the difference? What makes the PVHVM version
> work?
 
Please don't use HTML in emails.

PVHVM Linux guests setup interrupts differently: they request an event
channel for each legacy interrupt or MSI/MSI-X, then the hypervisor uses
these event channels to inject notifications into the guest, rather
than emulated interrupts or emulated MSIs.

Reading again the description of the bug, wouldn't it be better to just
the fix the problem in Linux?
In fact this looks like a bug in intel_detect_pch(): QEMU is emulating a
PCI-PCI bridge and the driver is checking for an PCI-ISA bridge (to help
with virtualization?). Moreover it only checks the first PCI-ISA bridge.

As far as I know Xen has never exposed a PCI-ISA bridge with vendor ==
Intel to the guest.


 Â
>       -----Original Message-----
>       From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
>       Sent: Monday, December 10, 2012 4:27 AM
>       To: G.R.
>       Cc: xen-devel; Stefano Stabellini; Kay, Allen M; xiantao.zhang@intel; 
> Xu, Dongxiao; Dong, Eddie
>       Subject: Re: intel IGD driver intel_detect_pch() failure
> 
>       CC'ing some engineers that could have some useful suggestions
> 
>       On Mon, 10 Dec 2012, G.R. wrote:
>       > Hello, could anybody help?
>       >
>       > On Sun, Dec 9, 2012 at 1:00 PM, G.R. 
> <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
>       > Â Â Â 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