Mailing List Archive

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 work 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

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@users.sourceforge.net>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
>

Hello, could anybody help?

On Sun, Dec 9, 2012 at 1:00 PM, G.R. <firemeteor@users.sourceforge.net>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@users.sourceforge.net>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
>>
>
>

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@users.sourceforge.net> 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@users.sourceforge.net> 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
>
>
>
>
>

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

-----Original Message-----
From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
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@users.sourceforge.net> 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@users.sourceforge.net> 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@lists.xen.org
http://lists.xen.org/xen-devel

On Tue, Dec 11, 2012 at 2:15 AM, Kay, Allen M <allen.m.kay@intel.com> 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?

Thanks,
Timothy



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> 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@users.sourceforge.net>
> 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@users.sourceforge.net> 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
> >
> >
> >
> >
> >
>

On Tue, 11 Dec 2012, G.R. wrote:
>
> On Tue, Dec 11, 2012 at 2:15 AM, Kay, Allen M <allen.m.kay@intel.com> 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@eu.citrix.com]
> 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@users.sourceforge.net> 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@users.sourceforge.net> 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
> >
> >
> >
> >
> >
>
>
>
>

On Tue, Dec 11, 2012 at 8:01 PM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:
>
> On Tue, 11 Dec 2012, G.R. wrote:
> >
> > On Tue, Dec 11, 2012 at 2:15 AM, Kay, Allen M <allen.m.kay@intel.com>
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.
>

I'm using gmail and not sure how to control html formatting.
I explicitly use 'remove formatting' this time, does it look better now?
Sorry for the inconvenience.

>
> 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.
>
Will this affect the result of pci_get_class() as called by the intel
driver?
If not, this can still not explain the different behavior.
Maybe I need to do one more experiment when I got time.

>
> 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.
>
But why do xen expose the PCI-ISA bridge in host as a PCI-PCI bridge,
doesn't it sounds strange?

On Tue, 11 Dec 2012, G.R. wrote:
> On Tue, Dec 11, 2012 at 8:01 PM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >
> > On Tue, 11 Dec 2012, G.R. wrote:
> > >
> > > On Tue, Dec 11, 2012 at 2:15 AM, Kay, Allen M <allen.m.kay@intel.com> 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.
> >
>
> I'm using gmail and not sure how to control html formatting.
> I explicitly use 'remove formatting' this time, does it look better now?
> Sorry for the inconvenience.

It is still html. You just need to click on "<< Plain Text".


> > 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.
> >
> Will this affect the result of pci_get_class() as called by the intel driver?
> If not, this can still not explain the different behavior.
> Maybe I need to do one more experiment when I got time.

No, it doesn't.


> > 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.
> >
> But why do xen expose the PCI-ISA bridge in host as a PCI-PCI bridge, doesn't it sounds strange?

Yes, it does sound strange, possibly wrong.

>> > 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.
>> >
>> Will this affect the result of pci_get_class() as called by the intel driver?
>> If not, this can still not explain the different behavior.
>> Maybe I need to do one more experiment when I got time.
>
> No, it doesn't.
>
I've done more experiments last night and it turns out that I'm being
fooled previously.
So actually none of the config (PV or not) correctly detected the PCH version.
The magic my debian PVHVM build works is in the script maintained grub config,
which automatically loads some VGA / FB driver to show image background.
The manual maintained grub config for openelec is quick && dirty and
does not have such fancy stuff.
Manually adding such VGA / FB driver to grub config could also 'fix'
the output issue.

However, this is a real issue that failing to detect PCH version in
the driver, even though the output can be made available through grub.
Driver code path specific to new PCH version is simply missed with
this issue which could potentially lead to other issues.

Could you xen && intel developers sit down to discuss and come up with
a formal solution?
I can foresee that cooperation is required on this topic.

Thanks,
Timothy

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

On Thu, 13 Dec 2012, G.R. wrote:
> >> > 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.
> >> >
> >> Will this affect the result of pci_get_class() as called by the intel driver?
> >> If not, this can still not explain the different behavior.
> >> Maybe I need to do one more experiment when I got time.
> >
> > No, it doesn't.
> >
> I've done more experiments last night and it turns out that I'm being
> fooled previously.
> So actually none of the config (PV or not) correctly detected the PCH version.
> The magic my debian PVHVM build works is in the script maintained grub config,
> which automatically loads some VGA / FB driver to show image background.
> The manual maintained grub config for openelec is quick && dirty and
> does not have such fancy stuff.
> Manually adding such VGA / FB driver to grub config could also 'fix'
> the output issue.
>
> However, this is a real issue that failing to detect PCH version in
> the driver, even though the output can be made available through grub.
> Driver code path specific to new PCH version is simply missed with
> this issue which could potentially lead to other issues.
>
> Could you xen && intel developers sit down to discuss and come up with
> a formal solution?
> I can foresee that cooperation is required on this topic.

Does this patch work for you?



diff --git a/hw/pci.c b/hw/pci.c
index f051de1..d371bd7 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -871,11 +871,6 @@ void pci_unplug_netifs(void)
}
}

-typedef struct {
- PCIDevice dev;
- PCIBus *bus;
-} PCIBridge;
-
void pci_bridge_write_config(PCIDevice *d,
uint32_t address, uint32_t val, int len)
{
diff --git a/hw/pci.h b/hw/pci.h
index edc58b6..c2acab9 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -222,6 +222,11 @@ struct PCIDevice {
int irq_state[4];
};

+typedef struct {
+ PCIDevice dev;
+ PCIBus *bus;
+} PCIBridge;
+
extern char direct_pci_str[];
extern int direct_pci_msitranslate;
extern int direct_pci_power_mgmt;
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index c6f8869..d8e789f 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -3,6 +3,7 @@
*/

#include "pass-through.h"
+#include "pci.h"
#include "pci/header.h"
#include "pci/pci.h"

@@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);

- if ( vid == PCI_VENDOR_ID_INTEL )
- pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
- pch_map_irq, "intel_bridge_1f");
+ if (vid == PCI_VENDOR_ID_INTEL) {
+ PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
+ sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
+
+ pci_config_set_vendor_id(s->dev.config, vid);
+ pci_config_set_device_id(s->dev.config, did);
+
+ s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
+ s->dev.config[PCI_COMMAND + 1] = 0x00;
+ s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
+ s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
+ s->dev.config[PCI_REVISION] = rid;
+ s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
+ pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
+ s->dev.config[PCI_LATENCY_TIMER] = 0x10;
+ s->dev.config[PCI_HEADER_TYPE] = 0x81;
+ s->dev.config[PCI_SEC_STATUS] = 0xa0;
+
+ s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
+ }
}

uint32_t igd_read_opregion(struct pt_dev *pci_dev)

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

On Thu, Dec 13, 2012 at 8:43 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>
> Does this patch work for you?
>

It appears that you change the exposed 1f.0 bridge into an ISA bridge.
The driver should be able to recognize it -- as long as it is not
hidden by the PIIX3 bridge.
I wonder if there is way to entirely override that one...
But anyway I'll try it out first.

>
>
> diff --git a/hw/pci.c b/hw/pci.c
> index f051de1..d371bd7 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -871,11 +871,6 @@ void pci_unplug_netifs(void)
> }
> }
>
> -typedef struct {
> - PCIDevice dev;
> - PCIBus *bus;
> -} PCIBridge;
> -
> void pci_bridge_write_config(PCIDevice *d,
> uint32_t address, uint32_t val, int len)
> {
> diff --git a/hw/pci.h b/hw/pci.h
> index edc58b6..c2acab9 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -222,6 +222,11 @@ struct PCIDevice {
> int irq_state[4];
> };
>
> +typedef struct {
> + PCIDevice dev;
> + PCIBus *bus;
> +} PCIBridge;
> +
> extern char direct_pci_str[];
> extern int direct_pci_msitranslate;
> extern int direct_pci_power_mgmt;
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index c6f8869..d8e789f 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -3,6 +3,7 @@
> */
>
> #include "pass-through.h"
> +#include "pci.h"
> #include "pci/header.h"
> #include "pci/pci.h"
>
> @@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
> did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
> rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
>
> - if ( vid == PCI_VENDOR_ID_INTEL )
> - pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
> - pch_map_irq, "intel_bridge_1f");
> + if (vid == PCI_VENDOR_ID_INTEL) {
> + PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
> + sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
> +
> + pci_config_set_vendor_id(s->dev.config, vid);
> + pci_config_set_device_id(s->dev.config, did);
> +
> + s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
> + s->dev.config[PCI_COMMAND + 1] = 0x00;
> + s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
> + s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
> + s->dev.config[PCI_REVISION] = rid;
> + s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
> + pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
> + s->dev.config[PCI_LATENCY_TIMER] = 0x10;
> + s->dev.config[PCI_HEADER_TYPE] = 0x81;
> + s->dev.config[PCI_SEC_STATUS] = 0xa0;
> +
> + s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
> + }
> }
>
> uint32_t igd_read_opregion(struct pt_dev *pci_dev)

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

On Thu, Dec 13, 2012 at 10:33 PM, G.R. <firemeteor@users.sourceforge.net> wrote:
> On Thu, Dec 13, 2012 at 8:43 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>>
>> Does this patch work for you?
>>
>
> It appears that you change the exposed 1f.0 bridge into an ISA bridge.
> The driver should be able to recognize it -- as long as it is not
> hidden by the PIIX3 bridge.
> I wonder if there is way to entirely override that one...
> But anyway I'll try it out first.
>

Stefano, your patch does not produce an ISA bridge as expected.
The device as viewed from the domU is like this:
00:1f.0 Non-VGA unclassified device [0000]: Intel Corporation H77
Express Chipset LPC Controller [8086:1e4a] (rev 04)

I'm on the latest 4.2-testing branch just synced && built for your patch.

Thanks,
Timothy

>>
>>
>> diff --git a/hw/pci.c b/hw/pci.c
>> index f051de1..d371bd7 100644
>> --- a/hw/pci.c
>> +++ b/hw/pci.c
>> @@ -871,11 +871,6 @@ void pci_unplug_netifs(void)
>> }
>> }
>>
>> -typedef struct {
>> - PCIDevice dev;
>> - PCIBus *bus;
>> -} PCIBridge;
>> -
>> void pci_bridge_write_config(PCIDevice *d,
>> uint32_t address, uint32_t val, int len)
>> {
>> diff --git a/hw/pci.h b/hw/pci.h
>> index edc58b6..c2acab9 100644
>> --- a/hw/pci.h
>> +++ b/hw/pci.h
>> @@ -222,6 +222,11 @@ struct PCIDevice {
>> int irq_state[4];
>> };
>>
>> +typedef struct {
>> + PCIDevice dev;
>> + PCIBus *bus;
>> +} PCIBridge;
>> +
>> extern char direct_pci_str[];
>> extern int direct_pci_msitranslate;
>> extern int direct_pci_power_mgmt;
>> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
>> index c6f8869..d8e789f 100644
>> --- a/hw/pt-graphics.c
>> +++ b/hw/pt-graphics.c
>> @@ -3,6 +3,7 @@
>> */
>>
>> #include "pass-through.h"
>> +#include "pci.h"
>> #include "pci/header.h"
>> #include "pci/pci.h"
>>
>> @@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
>> did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>> rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
>>
>> - if ( vid == PCI_VENDOR_ID_INTEL )
>> - pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
>> - pch_map_irq, "intel_bridge_1f");
>> + if (vid == PCI_VENDOR_ID_INTEL) {
>> + PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
>> + sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
>> +
>> + pci_config_set_vendor_id(s->dev.config, vid);
>> + pci_config_set_device_id(s->dev.config, did);
>> +
>> + s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
>> + s->dev.config[PCI_COMMAND + 1] = 0x00;
>> + s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
>> + s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
>> + s->dev.config[PCI_REVISION] = rid;
>> + s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
>> + pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
>> + s->dev.config[PCI_LATENCY_TIMER] = 0x10;
>> + s->dev.config[PCI_HEADER_TYPE] = 0x81;
>> + s->dev.config[PCI_SEC_STATUS] = 0xa0;
>> +
>> + s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
>> + }
>> }
>>
>> uint32_t igd_read_opregion(struct pt_dev *pci_dev)

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

On Fri, Dec 14, 2012 at 1:39 AM, G.R. <firemeteor@users.sourceforge.net> wrote:
> On Thu, Dec 13, 2012 at 10:33 PM, G.R. <firemeteor@users.sourceforge.net> wrote:
>> On Thu, Dec 13, 2012 at 8:43 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>>
>>> Does this patch work for you?
>>>
>>
>> It appears that you change the exposed 1f.0 bridge into an ISA bridge.
>> The driver should be able to recognize it -- as long as it is not
>> hidden by the PIIX3 bridge.
>> I wonder if there is way to entirely override that one...
>> But anyway I'll try it out first.
>>
>
> Stefano, your patch does not produce an ISA bridge as expected.
> The device as viewed from the domU is like this:
> 00:1f.0 Non-VGA unclassified device [0000]: Intel Corporation H77
> Express Chipset LPC Controller [8086:1e4a] (rev 04)
>
> I'm on the latest 4.2-testing branch just synced && built for your patch.
>

Some more info from lspci:

Intel ISA bridge as seen from dom0:
00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC
Controller (rev 04)
00: 86 80 4a 1e 07 00 10 02 04 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 4a 1e
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

After exposed to domU
00:1f.0 Non-VGA unclassified device: Intel Corporation H77 Express
Chipset LPC Controller (rev 04)
00: 86 80 4a 1e 07 00 a0 00 04 00 01 06 00 10 81 00
10: 00 50 42 f1 10 50 42 f1 00 01 01 f1 30 50 42 f1
20: 40 50 42 f1 50 50 42 f1 00 00 00 00 f4 1a 00 11
30: 60 50 42 f1 00 00 00 00 00 00 00 00 00 00 00 00

The PIIX3 ISA bridge as emulated by qemu:

00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00: 86 80 00 70 07 00 00 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f4 1a 00 11
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I have no idea if this is due to the header type set to 0x81 (pci-pci
bridge, multi-functional), or some other fields need to be cleared...


> Thanks,
> Timothy
>
>>>
>>>
>>> diff --git a/hw/pci.c b/hw/pci.c
>>> index f051de1..d371bd7 100644
>>> --- a/hw/pci.c
>>> +++ b/hw/pci.c
>>> @@ -871,11 +871,6 @@ void pci_unplug_netifs(void)
>>> }
>>> }
>>>
>>> -typedef struct {
>>> - PCIDevice dev;
>>> - PCIBus *bus;
>>> -} PCIBridge;
>>> -
>>> void pci_bridge_write_config(PCIDevice *d,
>>> uint32_t address, uint32_t val, int len)
>>> {
>>> diff --git a/hw/pci.h b/hw/pci.h
>>> index edc58b6..c2acab9 100644
>>> --- a/hw/pci.h
>>> +++ b/hw/pci.h
>>> @@ -222,6 +222,11 @@ struct PCIDevice {
>>> int irq_state[4];
>>> };
>>>
>>> +typedef struct {
>>> + PCIDevice dev;
>>> + PCIBus *bus;
>>> +} PCIBridge;
>>> +
>>> extern char direct_pci_str[];
>>> extern int direct_pci_msitranslate;
>>> extern int direct_pci_power_mgmt;
>>> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
>>> index c6f8869..d8e789f 100644
>>> --- a/hw/pt-graphics.c
>>> +++ b/hw/pt-graphics.c
>>> @@ -3,6 +3,7 @@
>>> */
>>>
>>> #include "pass-through.h"
>>> +#include "pci.h"
>>> #include "pci/header.h"
>>> #include "pci/pci.h"
>>>
>>> @@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
>>> did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>>> rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
>>>
>>> - if ( vid == PCI_VENDOR_ID_INTEL )
>>> - pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
>>> - pch_map_irq, "intel_bridge_1f");
>>> + if (vid == PCI_VENDOR_ID_INTEL) {
>>> + PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
>>> + sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
>>> +
>>> + pci_config_set_vendor_id(s->dev.config, vid);
>>> + pci_config_set_device_id(s->dev.config, did);
>>> +
>>> + s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
>>> + s->dev.config[PCI_COMMAND + 1] = 0x00;
>>> + s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
>>> + s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
>>> + s->dev.config[PCI_REVISION] = rid;
>>> + s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
>>> + pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
>>> + s->dev.config[PCI_LATENCY_TIMER] = 0x10;
>>> + s->dev.config[PCI_HEADER_TYPE] = 0x81;
>>> + s->dev.config[PCI_SEC_STATUS] = 0xa0;
>>> +
>>> + s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
>>> + }
>>> }
>>>
>>> uint32_t igd_read_opregion(struct pt_dev *pci_dev)

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

On Fri, Dec 14, 2012 at 10:39 AM, G.R. <firemeteor@users.sourceforge.net> wrote:
> On Fri, Dec 14, 2012 at 1:39 AM, G.R. <firemeteor@users.sourceforge.net> wrote:
>> On Thu, Dec 13, 2012 at 10:33 PM, G.R. <firemeteor@users.sourceforge.net> wrote:
>>> On Thu, Dec 13, 2012 at 8:43 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>>
>>>> Does this patch work for you?
>>>>
>>>
>>> It appears that you change the exposed 1f.0 bridge into an ISA bridge.
>>> The driver should be able to recognize it -- as long as it is not
>>> hidden by the PIIX3 bridge.
>>> I wonder if there is way to entirely override that one...
>>> But anyway I'll try it out first.
>>>
>>
>> Stefano, your patch does not produce an ISA bridge as expected.
>> The device as viewed from the domU is like this:
>> 00:1f.0 Non-VGA unclassified device [0000]: Intel Corporation H77
>> Express Chipset LPC Controller [8086:1e4a] (rev 04)
>>
>> I'm on the latest 4.2-testing branch just synced && built for your patch.
>>
>
> Some more info from lspci:
>
> Intel ISA bridge as seen from dom0:
> 00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC
> Controller (rev 04)
> 00: 86 80 4a 1e 07 00 10 02 04 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 49 18 4a 1e
> 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
>
> After exposed to domU
> 00:1f.0 Non-VGA unclassified device: Intel Corporation H77 Express
> Chipset LPC Controller (rev 04)
> 00: 86 80 4a 1e 07 00 a0 00 04 00 01 06 00 10 81 00
> 10: 00 50 42 f1 10 50 42 f1 00 01 01 f1 30 50 42 f1
> 20: 40 50 42 f1 50 50 42 f1 00 00 00 00 f4 1a 00 11
> 30: 60 50 42 f1 00 00 00 00 00 00 00 00 00 00 00 00
>
> The PIIX3 ISA bridge as emulated by qemu:
>
> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
> 00: 86 80 00 70 07 00 00 02 00 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 f4 1a 00 11
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> I have no idea if this is due to the header type set to 0x81 (pci-pci
> bridge, multi-functional), or some other fields need to be cleared...
>

I did another experiment to change the header type to 0x80.
The devices now shows up as an ISA bridge.
But as long as the PIIX3 bridge cannot be overridden, I need another
hack in intel driver to make it work.

This is the local hack I made, based on kernel 3.2.31.
But the function does not change in new version, other than new chip support.
Not sure if this change is acceptable to upstream...

--- i915_drv.c.orig 2012-10-10 10:31:37.000000000 +0800
+++ i915_drv.c 2012-12-14 19:10:32.000000000 +0800
@@ -303,6 +303,7 @@
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct pci_dev *pch;
+ unsigned found = 0;

/*
* The reason to probe ISA bridge instead of Dev31:Fun0 is to
@@ -311,11 +312,13 @@
* underneath. This is a requirement from virtualization team.
*/
pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL);
- if (pch) {
+ while (pch) {
if (pch->vendor == PCI_VENDOR_ID_INTEL) {
int id;
id = pch->device & INTEL_PCH_DEVICE_ID_MASK;

+ found = pch->device;
+
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_IBX;
DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
@@ -326,9 +329,21 @@
/* PantherPoint is CPT compatible */
dev_priv->pch_type = PCH_CPT;
DRM_DEBUG_KMS("Found PatherPoint PCH\n");
+ } else {
+ found = 0;
}
+ }
+ if (found) {
+ pci_dev_put(pch);
+ break;
+ } else {
+ struct pci_dev *curr = pch;
+ pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr);
+ pci_dev_put(curr);
}
- pci_dev_put(pch);
+ }
+ if (!found) {
+ DRM_DEBUG_KMS("intel PCH detect failed, nothing found\n");
}
}



>
>> Thanks,
>> Timothy
>>
>>>>
>>>>
>>>> diff --git a/hw/pci.c b/hw/pci.c
>>>> index f051de1..d371bd7 100644
>>>> --- a/hw/pci.c
>>>> +++ b/hw/pci.c
>>>> @@ -871,11 +871,6 @@ void pci_unplug_netifs(void)
>>>> }
>>>> }
>>>>
>>>> -typedef struct {
>>>> - PCIDevice dev;
>>>> - PCIBus *bus;
>>>> -} PCIBridge;
>>>> -
>>>> void pci_bridge_write_config(PCIDevice *d,
>>>> uint32_t address, uint32_t val, int len)
>>>> {
>>>> diff --git a/hw/pci.h b/hw/pci.h
>>>> index edc58b6..c2acab9 100644
>>>> --- a/hw/pci.h
>>>> +++ b/hw/pci.h
>>>> @@ -222,6 +222,11 @@ struct PCIDevice {
>>>> int irq_state[4];
>>>> };
>>>>
>>>> +typedef struct {
>>>> + PCIDevice dev;
>>>> + PCIBus *bus;
>>>> +} PCIBridge;
>>>> +
>>>> extern char direct_pci_str[];
>>>> extern int direct_pci_msitranslate;
>>>> extern int direct_pci_power_mgmt;
>>>> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
>>>> index c6f8869..d8e789f 100644
>>>> --- a/hw/pt-graphics.c
>>>> +++ b/hw/pt-graphics.c
>>>> @@ -3,6 +3,7 @@
>>>> */
>>>>
>>>> #include "pass-through.h"
>>>> +#include "pci.h"
>>>> #include "pci/header.h"
>>>> #include "pci/pci.h"
>>>>
>>>> @@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
>>>> did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>>>> rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
>>>>
>>>> - if ( vid == PCI_VENDOR_ID_INTEL )
>>>> - pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
>>>> - pch_map_irq, "intel_bridge_1f");
>>>> + if (vid == PCI_VENDOR_ID_INTEL) {
>>>> + PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
>>>> + sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
>>>> +
>>>> + pci_config_set_vendor_id(s->dev.config, vid);
>>>> + pci_config_set_device_id(s->dev.config, did);
>>>> +
>>>> + s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
>>>> + s->dev.config[PCI_COMMAND + 1] = 0x00;
>>>> + s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
>>>> + s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
>>>> + s->dev.config[PCI_REVISION] = rid;
>>>> + s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
>>>> + pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
>>>> + s->dev.config[PCI_LATENCY_TIMER] = 0x10;
>>>> + s->dev.config[PCI_HEADER_TYPE] = 0x81;
>>>> + s->dev.config[PCI_SEC_STATUS] = 0xa0;
>>>> +
>>>> + s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
>>>> + }
>>>> }
>>>>
>>>> uint32_t igd_read_opregion(struct pt_dev *pci_dev)

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

On Fri, 14 Dec 2012, G.R. wrote:
> I did another experiment to change the header type to 0x80.
> The devices now shows up as an ISA bridge.

Great! Could you please resend the patch with your change to xen-devel?


> But as long as the PIIX3 bridge cannot be overridden, I need another
> hack in intel driver to make it work.
>
> This is the local hack I made, based on kernel 3.2.31.
> But the function does not change in new version, other than new chip support.
> Not sure if this change is acceptable to upstream...

I am not the maintainer of the i915 driver, but my feeling is that it is
acceptable.
However when making changes to Linux, you need to make them against the
the latest release or one of the latest RCs of Linus' git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git),
for example v3.7. You also need to generate the patch with git diff.


> --- i915_drv.c.orig 2012-10-10 10:31:37.000000000 +0800
> +++ i915_drv.c 2012-12-14 19:10:32.000000000 +0800
> @@ -303,6 +303,7 @@
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct pci_dev *pch;
> + unsigned found = 0;

You don't need to introduce found: I would just use "continue" in the
while loop if there isn't a match and "break" at the first good match.

>
> /*
> * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> @@ -311,11 +312,13 @@
> * underneath. This is a requirement from virtualization team.
> */
> pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL);
> - if (pch) {
> + while (pch) {
> if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> int id;
> id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>
> + found = pch->device;
> +
> if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> dev_priv->pch_type = PCH_IBX;
> DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> @@ -326,9 +329,21 @@
> /* PantherPoint is CPT compatible */
> dev_priv->pch_type = PCH_CPT;
> DRM_DEBUG_KMS("Found PatherPoint PCH\n");
> + } else {
> + found = 0;
> }
> + }
> + if (found) {
> + pci_dev_put(pch);
> + break;
> + } else {
> + struct pci_dev *curr = pch;
> + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr);
> + pci_dev_put(curr);
> }
> - pci_dev_put(pch);
> + }
> + if (!found) {
> + DRM_DEBUG_KMS("intel PCH detect failed, nothing found\n");
> }
> }

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

On Fri, Dec 14, 2012 at 8:59 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 14 Dec 2012, G.R. wrote:
>> I did another experiment to change the header type to 0x80.
>> The devices now shows up as an ISA bridge.
>
> Great! Could you please resend the patch with your change to xen-devel?
>
Sure, do I need to start a separate thread? Or simply send a follow up?
>
>> But as long as the PIIX3 bridge cannot be overridden, I need another
>> hack in intel driver to make it work.
>>
>> This is the local hack I made, based on kernel 3.2.31.
>> But the function does not change in new version, other than new chip support.
>> Not sure if this change is acceptable to upstream...
>
> I am not the maintainer of the i915 driver, but my feeling is that it is
> acceptable.
> However when making changes to Linux, you need to make them against the
> the latest release or one of the latest RCs of Linus' git tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git),
> for example v3.7. You also need to generate the patch with git diff.
>

Adding Intel guys to To list.
Could you check the change I made to the IGD driver.
If you think that's okay, I can create a patch against the latest 3.7 kernel.

>
>> --- i915_drv.c.orig 2012-10-10 10:31:37.000000000 +0800
>> +++ i915_drv.c 2012-12-14 19:10:32.000000000 +0800
>> @@ -303,6 +303,7 @@
>> {
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct pci_dev *pch;
>> + unsigned found = 0;
>
> You don't need to introduce found: I would just use "continue" in the
> while loop if there isn't a match and "break" at the first good match.
>
That was part of the debugging log I added several days ago to root
cause the issue.
I'll have a clean version if upstream is okay with this 'while' change.

>>
>> /*
>> * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>> @@ -311,11 +312,13 @@
>> * underneath. This is a requirement from virtualization team.
>> */
>> pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL);
>> - if (pch) {
>> + while (pch) {
>> if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>> int id;
>> id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>
>> + found = pch->device;
>> +
>> if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>> dev_priv->pch_type = PCH_IBX;
>> DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
>> @@ -326,9 +329,21 @@
>> /* PantherPoint is CPT compatible */
>> dev_priv->pch_type = PCH_CPT;
>> DRM_DEBUG_KMS("Found PatherPoint PCH\n");
>> + } else {
>> + found = 0;
>> }
>> + }
>> + if (found) {
>> + pci_dev_put(pch);
>> + break;
>> + } else {
>> + struct pci_dev *curr = pch;
>> + pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, curr);
>> + pci_dev_put(curr);
>> }
>> - pci_dev_put(pch);
>> + }
>> + if (!found) {
>> + DRM_DEBUG_KMS("intel PCH detect failed, nothing found\n");
>> }
>> }

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