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

Re: [Xen-devel] 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

 


Rackspace

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