[Bug]: Continue gracefully on unavailable resource spaces #444
Assignees
Labels
Comments
kuqin12
added
state:needs-triage
github-actions
bot
added
state:needs-owner
github-actions
bot
removed
the
state:needs-owner
|
@Javagedes adding you as an assignee for this issue, per @spbrogan's suggestion. Can you please take a look at this? We can sync offline to catch up with the details. Thanks! |
5 tasks
Javagedes
added a commit
that referenced
this issue
Jul 6, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
to kenlautner/mu_basecore
that referenced
this issue
Jul 13, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes microsoft#444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Oct 17, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Oct 17, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Oct 18, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Oct 18, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Oct 19, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Oct 20, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Oct 23, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Dec 16, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Dec 18, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this issue
Dec 18, 2023
## Description Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not. closes #444 - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Will be platform tested ## Integration Instructions N/A --------- Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an existing issue for this?
Current Behavior
On certain platforms, such as ARM based systems, there is not any available IO space.
Currently the PCI driver will exit the resource allocation if any of the requested resources are not available.
Expected Behavior
The request is that, if an endpoint is requesting IO space, there should be a way to continue gracefully without allocating any IO resources.
Steps To Reproduce
Build a system firmware with top of basecore and flash on to a device that has the above behavior on requesting IO spaces.
Once the endpoint requested IO spaces, the subsequent endpoint will no longer be able to allocate any resources.
Build Environment
Version Information
Urgency
Medium
Are you going to fix this?
Someone else needs to fix it
Do you need maintainer feedback?
No maintainer feedback needed
Anything else?
No response
The text was updated successfully, but these errors were encountered: