[edk2-devel] question about PCI bridge's bus range window configure's save and restore

[edk2-devel] question about PCI bridge's bus range window configure's save and restore

[Tiger Liu(BJ-RD)]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

Hi, Experts:
I have a question about PCI Bridge’s config space’s save and restore.

Pci bus driver configured PCI Bridges’ secondary bus number register and subordinate bus number register.

So, if system resumes from S3(Suspend to ram) state, who is responsible for restoring PCI Bridges’ secondary bus number / subordinate bus number registers’ content?

Will the OS be responsible for it?

Thanks



保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

[-- Attachment #2: Type: text/html, Size: 4863 bytes --]

答复: [edk2-devel] question about PCI bridge's bus range window configure's save and restore

[wangxiao.bj]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

It’s done by BIOS pei s3 resume code.  Restored register value saved  while BIOS normal POST BY BootScriptExecutor.  You can refer  gEfiPeiS3Resume2Ppi  usage

Thanks

发件人: devel@edk2.groups.io [mailto:devel@edk2.groups.io] 代表 Tiger Liu(BJ-RD)
发送时间: 2020年8月10日 17:32
收件人: devel@edk2.groups.io
主题: [edk2-devel] question about PCI bridge's bus range window configure's save and restore



Hi, Experts:

I have a question about PCI Bridge’s config space’s save and restore.



Pci bus driver configured PCI Bridges’ secondary bus number register and subordinate bus number register.



So, if system resumes from S3(Suspend to ram) state, who is responsible for restoring PCI Bridges’ secondary bus number / subordinate bus number registers’ content?



Will the OS be responsible for it?



Thanks





保密声明：

本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。

CONFIDENTIAL NOTE:

This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.




[-- Attachment #2: Type: text/html, Size: 8482 bytes --]

Re: 答复: [edk2-devel] question about PCI bridge's bus range window configure's save and restore

[Laszlo Ersek]

On 08/10/20 13:54, Ric Wang (王晓) wrote:
> It’s done by BIOS pei s3 resume code.  Restored register value saved  while BIOS normal POST BY BootScriptExecutor.  You can refer  gEfiPeiS3Resume2Ppi  usage

That doesn't seem right. The S3 boot script is composed by platform
drivers in the firmware, for restoring platform hardware state.

But the registers in question, in PCI config space, are specified in the
PCI(e) spec(s), and the OS is virtually guaranteed to have drivers for
PCI bridges / PCIe ports. The OS may even re-enumerate the PCI hierarchy
(overriding what the firmware put in place), after which restoring the
same configuration in the firmware, during S3 resume, would be wrong.

Considering edk2, because PciBusDxe sets the bus numbers initially
(possibly influenced by the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL
provider), if S3 boot script opcodes were saved for this, we should see
PciBusDxe consume "gEfiS3SaveStateProtocolGuid". But it doesn't.

If at S3, the port goes into D3hot state or shallower, then its config
space is not lost. If the port goes into D3, then the OS knows it has to
reprogram it after resume. That's my (very superficial) understanding
anyway, from the ACPI spec.

The Linux kernel seems to have a lot of logic around "bridge_d3" under
"drivers/pci/".

Thanks
Laszlo


> Thanks
> 
> 发件人: devel@edk2.groups.io [mailto:devel@edk2.groups.io] 代表 Tiger Liu(BJ-RD)
> 发送时间: 2020年8月10日 17:32
> 收件人: devel@edk2.groups.io
> 主题: [edk2-devel] question about PCI bridge's bus range window configure's save and restore
> 
> 
> 
> Hi, Experts:
> 
> I have a question about PCI Bridge’s config space’s save and restore.
> 
> 
> 
> Pci bus driver configured PCI Bridges’ secondary bus number register and subordinate bus number register.
> 
> 
> 
> So, if system resumes from S3(Suspend to ram) state, who is responsible for restoring PCI Bridges’ secondary bus number / subordinate bus number registers’ content?
> 
> 
> 
> Will the OS be responsible for it?
> 
> 
> 
> Thanks
> 
> 
> 
> 
> 
> 保密声明：
> 
> 本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> 
> CONFIDENTIAL NOTE:
> 
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
> 
> 
> 
> 
> 
> 

Re: 答复: [edk2-devel] question about PCI bridge's bus range window configure's save and restore

[Feng Libo]

[-- Attachment #1: Type: text/plain, Size: 3248 bytes --]

When resuming from S3, UEFI skips the memory initialization and PCIe enumeration, just brings memory out of self-refresh state and jumps to the resuming point in memory. OS doesn't re-enumerate, either.


The interesting question is if I plug or unplug a PCIe device when system in S3 state, then what will happen when S3 resuming?


Thanks


Best Regards


Feng Libo


--

Best Regards


Feng Libo
ZD Technology (Beijing) Co., Ltd



发件人："Laszlo Ersek" <lersek@redhat.com>
发送日期：2020-08-11 05:32:37
收件人：devel@edk2.groups.io,wangxiao.bj@inspur.com,"tigerliu@zhaoxin.com" <tigerliu@zhaoxin.com>
主题：Re: 答复: [edk2-devel] question about PCI bridge's bus range window configure's save and restore>On 08/10/20 13:54, Ric Wang (王晓) wrote:
>> It’s done by BIOS pei s3 resume code.  Restored register value saved  while BIOS normal POST BY BootScriptExecutor.  You can refer  gEfiPeiS3Resume2Ppi  usage
>
>That doesn't seem right. The S3 boot script is composed by platform
>drivers in the firmware, for restoring platform hardware state.
>
>But the registers in question, in PCI config space, are specified in the
>PCI(e) spec(s), and the OS is virtually guaranteed to have drivers for
>PCI bridges / PCIe ports. The OS may even re-enumerate the PCI hierarchy
>(overriding what the firmware put in place), after which restoring the
>same configuration in the firmware, during S3 resume, would be wrong.
>
>Considering edk2, because PciBusDxe sets the bus numbers initially
>(possibly influenced by the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL
>provider), if S3 boot script opcodes were saved for this, we should see
>PciBusDxe consume "gEfiS3SaveStateProtocolGuid". But it doesn't.
>
>If at S3, the port goes into D3hot state or shallower, then its config
>space is not lost. If the port goes into D3, then the OS knows it has to
>reprogram it after resume. That's my (very superficial) understanding
>anyway, from the ACPI spec.
>
>The Linux kernel seems to have a lot of logic around "bridge_d3" under
>"drivers/pci/".
>
>Thanks
>Laszlo
>
>
>> Thanks
>> 
>> 发件人: devel@edk2.groups.io [mailto:devel@edk2.groups.io] 代表 Tiger Liu(BJ-RD)
>> 发送时间: 2020年8月10日 17:32
>> 收件人: devel@edk2.groups.io
>> 主题: [edk2-devel] question about PCI bridge's bus range window configure's save and restore
>> 
>> 
>> 
>> Hi, Experts:
>> 
>> I have a question about PCI Bridge’s config space’s save and restore.
>> 
>> 
>> 
>> Pci bus driver configured PCI Bridges’ secondary bus number register and subordinate bus number register.
>> 
>> 
>> 
>> So, if system resumes from S3(Suspend to ram) state, who is responsible for restoring PCI Bridges’ secondary bus number / subordinate bus number registers’ content?
>> 
>> 
>> 
>> Will the OS be responsible for it?
>> 
>> 
>> 
>> Thanks
>> 
>> 
>> 
>> 
>> 
>> 保密声明：
>> 
>> 本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
>> 
>> CONFIDENTIAL NOTE:
>> 
>> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3959 bytes --]