Prev: virtually indexed array library.
Next: linux-next: Tree for July 27 (xen)
From: Rafael J. Wysocki on 27 Jul 2010 14:40
On Tuesday, July 27, 2010, Kenji Kaneshige wrote:
> Hi,
>
> If I understand your patch correctly, the PCIe port services work
> only when firmware grants all the controls for port services with
> your patch. Correct?

Yes, that's correct.

> I think this will break PCIe services currently working. For example,
> firmware doesn't grant PCIe AER control on my hardware. On the other
> hand, firmware grants PCIe native hot-plug control on the same machine.
> So I think PCIe hot-plug will not work with your patch.

It won't, but the question is if it should. Namely, PCIe native hot-plug
requires control of the PCIe capability structure, which is also used for
AER, so the BIOS granting control of the PCIe capability structure and
not granting control of AER is arguably broken.

> Another example, what would happen on the platform that doesn't have any PCIe
> hot-plug slot? I guess firmware doesn't grant PCIe native hot-plug control on
> that environment. So I think all the other PCIe port services would
> not work on such platform.

You would be surprised. :-)

> My suggestion is that
>
> (1) Query all controls for PCIe port services and see what controls
> will be granted to OS by firmware.

We do that already.

> (2) Request all the controls acquired in step (1) at the same time.

Yes, we can do that, although it would complicate things quite a bit and I'm
not sure that's _really_ necessary, given that all of the native services
require access to the PCIe capability structure and once _that_ is granted,
the BIOS has no reason not to grant any other bits.

> (3) Create PCIe port services for those controls.

I don't really think (3) is necessary in that case. It should be OK not to
load a service driver, in which case the service will simply be disabled.

> What do you think about this?
>
> I think there is still a problem that needs to be addressed. The problem
> is that if ACPIPHP (ACPI based hot-plug driver) is required for PCIe hot-
> plug, all the PCIe port services needs to be disabled. I don't think it
> is acceptable for ACPIPHP users.

I'm not sure what you mean. The $subject patch (rather the last version of it
at https://patchwork.kernel.org/patch/114127/) doesn't change the existing
behavior in that respect other than PCIeHP will not be enabled without PME and
possibly AER.

Certainly, though, our current behavior is wrong, since all of the port service
drivers request OSC_PCI_EXPRESS_CAP_STRUCTURE_CONTROL on their own, which leads
to problems in real systems.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 27 Jul 2010 14:50
On Tuesday, July 27, 2010, Matthew Garrett wrote:
> On Tue, Jul 27, 2010 at 09:43:41AM +0900, Kenji Kaneshige wrote:
>
> > I think this will break PCIe services currently working. For example,
> > firmware doesn't grant PCIe AER control on my hardware. On the other
> > hand, firmware grants PCIe native hot-plug control on the same machine.
> > So I think PCIe hot-plug will not work with your patch. Another example,
> > what would happen on the platform that doesn't have any PCIe hot-plug
> > slot? I guess firmware doesn't grant PCIe native hot-plug control on
> > that environment. So I think all the other PCIe port services would
> > not work on such platform.
>
> I've done some more testing of this and found that my intial belief
> (supported by Microsoft's documentation...) that all PCIe support had to
> be handed over for any to be used is incorrect. It turns out that the
> firmware must support native hotplug, native power management and PCI
> express capability structure control - ie, SHPC and AER aren't required.

But the ACPI spec says quite explicitly that PCIe capability control is
necessary for AER as well.

> However, if any of the other flags are missing then Windows doesn't use
> any PCIe functionality on the system. That's the behaviour we wish to
> duplicate.

Agreed.

> > (1) Query all controls for PCIe port services and see what controls
> > will be granted to OS by firmware.
> > (2) Request all the controls acquired in step (1) at the same time.
> > (3) Create PCIe port services for those controls.
> >
> > What do you think about this?
>
> I think we need to do:
>
> (1) Query all controls and see what will be granted

This is done already by our current code running _OSC.

> (2) If any of bits 0, 2 and 4 are unsupported, disable all PCIe support
> via _OSC

I guess you mean "don't request control of that services at all"?

> (3) Ask for the set of supported bits & 0x1d

Really, if we try to treat native PME, native hot-plug and AER separately
(which is our current approach), we fall into a Catch 22 situation where
each of them needs PCIe capability control and once we've received the
control of that, we have no choice but to use the other native sevices as well.

> > I think there is still a problem that needs to be addressed. The
> > problem is that if ACPIPHP (ACPI based hot-plug driver) is required
> > for PCIe hot- plug, all the PCIe port services needs to be disabled. I
> > don't think it is acceptable for ACPIPHP users.
>
> I believe that that's the only way Windows will work on their system,
> which generally implies that that's how the machine was intended to run.

Agreed.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 28 Jul 2010 07:00
On Wednesday, July 28, 2010, Hidetoshi Seto wrote:
> Hi,
>
> (2010/07/25 8:05), Rafael J. Wysocki wrote:
> > It turns out that asking ACPI BIOS, through _OSC, for control of each
> > PCIe port native service individually sometimes confuses the BIOS if
> > one sevice is requested while the others are not (eg. requesting
> > control of the native PCIe PME without requesting control of the
> > native PCIe hot-plug at the same time leads to interrupt storms on
> > some systems).
>
> Then why not invent quirks or something for such systems?
>
> IMHO it sounds like a BIOS bug since it should grant PME control to
> OS only when both of PME and pciehp (plus PCIe caps) are requested
> at same time.
>
> Did you confirm that the system also confuses when pciehp is requested
> without requesting PME?
> e.g. assume that some BIOS might behave:
> _OSC(pciehp) => OK
> _OSC(PME) => NG (bugs on shared interrupt?)
> _OSC(pciehp|PME) => OK
> _OSC(SHPC) => OK
> _OSC(pciehp|SHPC) => NG (must choose one, not both)
> _OSC(AER|SHPC) => OK

The problem is the PCIe capability structure that is requested by each of
them (except for SHPC). After granting it, the BIOS can't legitimately write
to the PCIe standard config registers, so it's reasonable to assume the kernel
will configure them from its perspective.

> I don't doubt that handling of _OSC needs some improvement...

Good. :-)

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: virtually indexed array library.
Next: linux-next: Tree for July 27 (xen)