Hi folks,
I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone please provide the answers or some ideas?
1. In SBSA it says that I/O virtualization property should be expressed by system firmware data. Then how to express this information by ACPI? Is only IORT table related? Or is there any examples?
2. In SBSA Section 4.1.3, page 14 as below, does the term "memory" here also include peripheral memory mapped IO spaces? Does the term "access" include both "read" and "write"? If write is also included, I'm afraid there might be some critical configuration registers which will cause unpredicted behavior or even system hang due to unintended random write.
3. In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it is not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?
4. In SBBR, for IPv6 related protocols, it is said that they are optional on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?
Thanks and regards.
Heyi
(+ Charles, Leif)
On 29 August 2016 at 08:45, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone please provide the answers or some ideas?
- In SBSA it says that I/O virtualization property should be expressed by
system firmware data. Then how to express this information by ACPI? Is only IORT table related? Or is there any examples?
- In SBSA Section 4.1.3, page 14 as below, does the term "memory" here
also include peripheral memory mapped IO spaces? Does the term "access" include both "read" and "write"? If write is also included, I'm afraid there might be some critical configuration registers which will cause unpredicted behavior or even system hang due to unintended random write.
' Populated or not' means it could be memory, MMIO or nothing at all.
If a write to a system register causes a deadlock as a side effect, that is fine. This section simply stipulates that the write *itself* should complete in finite time.
- In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it is
not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?
My guess is that this is an oversight. If PCIe is not mandatory, then this protocol should not be mandatory either.
4. In SBBR, for IPv6 related protocols, it is said that they are optional
on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?
Charles, Leif?
On Wed, Aug 31, 2016 at 10:31:36AM +0100, Ard Biesheuvel wrote:
(+ Charles, Leif)
On 29 August 2016 at 08:45, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone please provide the answers or some ideas?
- In SBSA it says that I/O virtualization property should be expressed by
system firmware data. Then how to express this information by ACPI? Is only IORT table related? Or is there any examples?
Pass. Graeme?
- In SBSA Section 4.1.3, page 14 as below, does the term "memory" here
also include peripheral memory mapped IO spaces? Does the term "access" include both "read" and "write"? If write is also included, I'm afraid there might be some critical configuration registers which will cause unpredicted behavior or even system hang due to unintended random write.
' Populated or not' means it could be memory, MMIO or nothing at all.
If a write to a system register causes a deadlock as a side effect, that is fine. This section simply stipulates that the write *itself* should complete in finite time.
What the section is explicitly about is unpopulated regions. Due to the nature of AXI, all transactions must complete - so historically most systems have included a "default slave", to which all accesses not covered by any explicit address decoding are routed.
Some AArch64 systems trigger an interrupt (and presumably don't deadlock) instead of generating this abort.
That's not contradicting Ard, only providing background.
- In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it is
not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?
My guess is that this is an oversight. If PCIe is not mandatory, then this protocol should not be mandatory either.
Interestingly, looking into this exposes a UEFI spec error: "In the case of EFI_LOAD_FILE2_PROTOCOL, the behavior is the same as above, except that it is only used if BootOption is FALSE"
(There is no BootOption, only BootPolicy.)
But EFI_LOAD_FILE2_PROTOCOL can also be used by anything wishing to load an image from a RAM location without describing it as a device path. So I think it needs to remain mandatory regardless.
(Although why isn't PCIe mandatory...?)
- In SBBR, for IPv6 related protocols, it is said that they are optional
on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?
Charles, Leif?
I don't see a value in shipping a system today that does not support IPv6, and the SBBR seems to agree :)
If a specific hardware component (for some reason) could not be made to support IPv6, it would still be possible for the platform to be compliant as long as the relevant protocols were supported by the firmware, so that a plug-in card could still make use of IPv6.
Regards,
Leif
On Wed, Aug 31, 2016 at 11:39:47AM +0100, Leif Lindholm wrote:
On Wed, Aug 31, 2016 at 10:31:36AM +0100, Ard Biesheuvel wrote:
(+ Charles, Leif)
On 29 August 2016 at 08:45, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone please provide the answers or some ideas?
- In SBSA it says that I/O virtualization property should be expressed by
system firmware data. Then how to express this information by ACPI? Is only IORT table related? Or is there any examples?
Pass. Graeme?
Not sure I quite understood the question, but IORT is where the SMMUs are defined.
Graeme
在 8/31/2016 6:39 PM, Leif Lindholm 写道:
On Wed, Aug 31, 2016 at 10:31:36AM +0100, Ard Biesheuvel wrote:
(+ Charles, Leif)
On 29 August 2016 at 08:45, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone please provide the answers or some ideas?
- In SBSA it says that I/O virtualization property should be expressed by
system firmware data. Then how to express this information by ACPI? Is only IORT table related? Or is there any examples?
Pass. Graeme?
- In SBSA Section 4.1.3, page 14 as below, does the term "memory" here
also include peripheral memory mapped IO spaces? Does the term "access" include both "read" and "write"? If write is also included, I'm afraid there might be some critical configuration registers which will cause unpredicted behavior or even system hang due to unintended random write.
' Populated or not' means it could be memory, MMIO or nothing at all.
If a write to a system register causes a deadlock as a side effect, that is fine. This section simply stipulates that the write *itself* should complete in finite time.
What the section is explicitly about is unpopulated regions. Due to the nature of AXI, all transactions must complete - so historically most systems have included a "default slave", to which all accesses not covered by any explicit address decoding are routed.
Some AArch64 systems trigger an interrupt (and presumably don't deadlock) instead of generating this abort.
That's not contradicting Ard, only providing background.
- In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it is
not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?
My guess is that this is an oversight. If PCIe is not mandatory, then this protocol should not be mandatory either.
Interestingly, looking into this exposes a UEFI spec error: "In the case of EFI_LOAD_FILE2_PROTOCOL, the behavior is the same as above, except that it is only used if BootOption is FALSE"
(There is no BootOption, only BootPolicy.)
But EFI_LOAD_FILE2_PROTOCOL can also be used by anything wishing to load an image from a RAM location without describing it as a device path. So I think it needs to remain mandatory regardless.
(Although why isn't PCIe mandatory...?)
I didn't see anything in SBSA saying that PCIe is mandatory; it always says that "if PCIe is supported, ...", so I suppose PCIe is not mandatory in ARM server. Please correct me if I'm wrong.
In EDK2 implementation, EFI_LOAD_FILE2_PROTOCOL is installed to PCI IO device handle, so if there is no PCIe support in UEFI, there will not be this protocol instance and it will become not compliant to SBBR.
- In SBBR, for IPv6 related protocols, it is said that they are optional
on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?
Charles, Leif?
I don't see a value in shipping a system today that does not support IPv6, and the SBBR seems to agree :)
If a specific hardware component (for some reason) could not be made to support IPv6, it would still be possible for the platform to be compliant as long as the relevant protocols were supported by the firmware, so that a plug-in card could still make use of IPv6.
Also from the view of implementation, shall we switch to network stack modules from NetworkPkg instead of MdeModulePkg? I think only the ones in NetworkPkg support IPv6.
Thanks.
Heyi
Regards,
Leif
On 2 September 2016 at 06:40, Heyi Guo heyi.guo@linaro.org wrote:
在 8/31/2016 6:39 PM, Leif Lindholm 写道:
On Wed, Aug 31, 2016 at 10:31:36AM +0100, Ard Biesheuvel wrote:
(+ Charles, Leif)
On 29 August 2016 at 08:45, Heyi Guo heyi.guo@linaro.org wrote:
[...]
- In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it
is not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?
My guess is that this is an oversight. If PCIe is not mandatory, then this protocol should not be mandatory either.
Interestingly, looking into this exposes a UEFI spec error: "In the case of EFI_LOAD_FILE2_PROTOCOL, the behavior is the same as above, except that it is only used if BootOption is FALSE"
(There is no BootOption, only BootPolicy.)
But EFI_LOAD_FILE2_PROTOCOL can also be used by anything wishing to load an image from a RAM location without describing it as a device path. So I think it needs to remain mandatory regardless.
(Although why isn't PCIe mandatory...?)
I didn't see anything in SBSA saying that PCIe is mandatory; it always says that "if PCIe is supported, ...", so I suppose PCIe is not mandatory in ARM server. Please correct me if I'm wrong.
In EDK2 implementation, EFI_LOAD_FILE2_PROTOCOL is installed to PCI IO device handle, so if there is no PCIe support in UEFI, there will not be this protocol instance and it will become not compliant to SBBR.
No, you shouldn't interpret it like that. The presence of the protocols can only be reasonably expected to be mandatory if the underlying devices are present as well. By the same reasoning, if support for the USB HID protocols were mandatory, that would not require you to have a keyboard or mouse connected in order to be compliant.
So what this means is, *if* a PCIe card with a UEFI compatible option ROM is plugged in, the firmware should produce the EFI_LOAD_FILE2_PROTOCOL protocol. If no PCIe slots exist, you can short circuit the above if to FALSE and remove the code and still be compliant.
- In SBBR, for IPv6 related protocols, it is said that they are optional
on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?
Charles, Leif?
I don't see a value in shipping a system today that does not support IPv6, and the SBBR seems to agree :)
If a specific hardware component (for some reason) could not be made to support IPv6, it would still be possible for the platform to be compliant as long as the relevant protocols were supported by the firmware, so that a plug-in card could still make use of IPv6.
Also from the view of implementation, shall we switch to network stack modules from NetworkPkg instead of MdeModulePkg? I think only the ones in NetworkPkg support IPv6.
Thanks.
Heyi
Regards,
Leif
On 09/01/2016 11:40 PM, Heyi Guo wrote:
在 8/31/2016 6:39 PM, Leif Lindholm 写道:
On Wed, Aug 31, 2016 at 10:31:36AM +0100, Ard Biesheuvel wrote:
(+ Charles, Leif)
On 29 August 2016 at 08:45, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone please provide the answers or some ideas?
- In SBSA it says that I/O virtualization property should be expressed by
system firmware data. Then how to express this information by ACPI? Is only IORT table related? Or is there any examples?
Pass. Graeme?
- In SBSA Section 4.1.3, page 14 as below, does the term "memory" here
also include peripheral memory mapped IO spaces? Does the term "access" include both "read" and "write"? If write is also included, I'm afraid there might be some critical configuration registers which will cause unpredicted behavior or even system hang due to unintended random write.
' Populated or not' means it could be memory, MMIO or nothing at all.
If a write to a system register causes a deadlock as a side effect, that is fine. This section simply stipulates that the write *itself* should complete in finite time.
What the section is explicitly about is unpopulated regions. Due to the nature of AXI, all transactions must complete - so historically most systems have included a "default slave", to which all accesses not covered by any explicit address decoding are routed.
Some AArch64 systems trigger an interrupt (and presumably don't deadlock) instead of generating this abort.
That's not contradicting Ard, only providing background.
- In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it is
not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?
My guess is that this is an oversight. If PCIe is not mandatory, then this protocol should not be mandatory either.
Interestingly, looking into this exposes a UEFI spec error: "In the case of EFI_LOAD_FILE2_PROTOCOL, the behavior is the same as above, except that it is only used if BootOption is FALSE"
(There is no BootOption, only BootPolicy.)
But EFI_LOAD_FILE2_PROTOCOL can also be used by anything wishing to load an image from a RAM location without describing it as a device path. So I think it needs to remain mandatory regardless.
(Although why isn't PCIe mandatory...?)
I didn't see anything in SBSA saying that PCIe is mandatory; it always says that "if PCIe is supported, ...", so I suppose PCIe is not mandatory in ARM server. Please correct me if I'm wrong.
I would have to double check the document, but there are several levels of SBSA compliance. IIRC, the lowest level may not require PCIe. So, you end up with clunky wording when trying to describe all levels of compliance. Perhaps the "if PCIe is supported" means "if the level of SBSA compliance you want to implement is greater than level 0 such that PCIe is required, then...".
In EDK2 implementation, EFI_LOAD_FILE2_PROTOCOL is installed to PCI IO device handle, so if there is no PCIe support in UEFI, there will not be this protocol instance and it will become not compliant to SBBR.
- In SBBR, for IPv6 related protocols, it is said that they are optional
on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?
Charles, Leif?
I don't see a value in shipping a system today that does not support IPv6, and the SBBR seems to agree :)
If a specific hardware component (for some reason) could not be made to support IPv6, it would still be possible for the platform to be compliant as long as the relevant protocols were supported by the firmware, so that a plug-in card could still make use of IPv6.
Also from the view of implementation, shall we switch to network stack modules from NetworkPkg instead of MdeModulePkg? I think only the ones in NetworkPkg support IPv6.
Thanks.
Heyi
Regards,
Leif
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
On Fri, Sep 02, 2016 at 01:40:11PM +0800, Heyi Guo wrote:
- In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it is
not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?
My guess is that this is an oversight. If PCIe is not mandatory, then this protocol should not be mandatory either.
Interestingly, looking into this exposes a UEFI spec error: "In the case of EFI_LOAD_FILE2_PROTOCOL, the behavior is the same as above, except that it is only used if BootOption is FALSE"
(There is no BootOption, only BootPolicy.)
But EFI_LOAD_FILE2_PROTOCOL can also be used by anything wishing to load an image from a RAM location without describing it as a device path. So I think it needs to remain mandatory regardless.
(Although why isn't PCIe mandatory...?)
I didn't see anything in SBSA saying that PCIe is mandatory; it always says that "if PCIe is supported, ...", so I suppose PCIe is not mandatory in ARM server. Please correct me if I'm wrong.
No, I was expressing a preference more than anything.
In EDK2 implementation, EFI_LOAD_FILE2_PROTOCOL is installed to PCI IO device handle, so if there is no PCIe support in UEFI, there will not be this protocol instance and it will become not compliant to SBBR.
Arguably, this would be a bug in EDK2. There is nothing explicitly tying EFI_LOAD_FILE2_PROTOCOL to PCIe, other than the latter needing the former for OptionROM..
- In SBBR, for IPv6 related protocols, it is said that they are optional
on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?
Charles, Leif?
I don't see a value in shipping a system today that does not support IPv6, and the SBBR seems to agree :)
If a specific hardware component (for some reason) could not be made to support IPv6, it would still be possible for the platform to be compliant as long as the relevant protocols were supported by the firmware, so that a plug-in card could still make use of IPv6.
Also from the view of implementation, shall we switch to network stack modules from NetworkPkg instead of MdeModulePkg? I think only the ones in NetworkPkg support IPv6.
Not switching, as some of the IP4 support is still in MdeModulePkg. Look to OvmfPkg/*.dsc for guidance. (Ard: we should fix this for ArmVirtPkg.)
Regards,
Leif
在 8/31/2016 5:31 PM, Ard Biesheuvel 写道:
(+ Charles, Leif)
On 29 August 2016 at 08:45, Heyi Guo <heyi.guo@linaro.org mailto:heyi.guo@linaro.org>wrote:
Hi folks, I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone please provide the answers or some ideas? 1. In SBSA it says that I/O virtualization property should be expressed by system firmware data. Then how to express this information by ACPI? Is only IORT table related? Or is there any examples? 2. In SBSA Section 4.1.3, page 14 as below, does the term "memory" here also include peripheral memory mapped IO spaces? Does the term "access" include both "read" and "write"? If write is also included, I'm afraid there might be some critical configuration registers which will cause unpredicted behavior or even system hang due to unintended random write.' Populated or not' means it could be memory, MMIO or nothing at all.
If a write to a system register causes a deadlock as a side effect, that is fine. This section simply stipulates that the write *itself* should complete in finite time.
That's reasonable indeed. Thanks Ard.
Heyi
3. In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it is not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?My guess is that this is an oversight. If PCIe is not mandatory, then this protocol should not be mandatory either.
4. In SBBR, for IPv6 related protocols, it is said that they are optional on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?Charles, Leif?
-
Al Stone -
Ard Biesheuvel -
graeme.gregory＠linaro.org -
Heyi Guo -
Leif Lindholm