This patch serial is about QEMU resource reserve capability finding in firmware.
Firstly, this fixes a logic bug. When the capability is truncated, return zero instead of the truncated offset. Secondly, this modified the debug messages when the capability is not found and when the vendor ID or device Id doesn't match REDHAT special ones.
Last, this enables the firmware recongizing the REDHAT PCI BRIDGE device ID, so that QEMU can also reserve PCI bridge resource capability.
Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability
src/fw/pciinit.c | 45 ++++++++++++++++++++++++++++----------------- src/hw/pci_ids.h | 1 + 2 files changed, 29 insertions(+), 17 deletions(-)
Return zero when finding truncated capability.
Signed-off-by: Jing Liu jing2.liu@linux.intel.com --- src/fw/pciinit.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 3a2f747..d2cea2b 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -539,6 +539,7 @@ static u8 pci_find_resource_reserve_capability(u16 bdf) if (cap_len < RES_RESERVE_CAP_SIZE) { dprintf(1, "PCI: QEMU resource reserve cap length %d is invalid\n", cap_len); + return 0; } } return cap;
Improve the debug message when QEMU resource reserve cap is not found and when the vendor-id or device-id does't match REDHAT special ones.
Signed-off-by: Jing Liu jing2.liu@linux.intel.com --- src/fw/pciinit.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index d2cea2b..62a32f1 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -541,10 +541,12 @@ static u8 pci_find_resource_reserve_capability(u16 bdf) cap_len); return 0; } + } else { + dprintf(1, "PCI: QEMU resource reserve cap not found\n"); } return cap; } else { - dprintf(1, "PCI: QEMU resource reserve cap not found\n"); + dprintf(1, "PCI: QEMU resource reserve cap VID or DID doesn't match.\n"); return 0; } }
Enable the firmware recognizing RedHat legacy PCI bridge device ID, so QEMU can reserve additional PCI bridge resource capability.
Signed-off-by: Jing Liu jing2.liu@linux.intel.com --- src/fw/pciinit.c | 50 +++++++++++++++++++++++++++++--------------------- src/hw/pci_ids.h | 1 + 2 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 62a32f1..795d84a 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -525,30 +525,38 @@ static void pci_bios_init_platform(void)
static u8 pci_find_resource_reserve_capability(u16 bdf) { - if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT && - pci_config_readw(bdf, PCI_DEVICE_ID) == - PCI_DEVICE_ID_REDHAT_ROOT_PORT) { - u8 cap = 0; - do { - cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, cap); - } while (cap && - pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET) != - REDHAT_CAP_RESOURCE_RESERVE); - if (cap) { - u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS); - if (cap_len < RES_RESERVE_CAP_SIZE) { - dprintf(1, "PCI: QEMU resource reserve cap length %d is invalid\n", - cap_len); - return 0; - } - } else { - dprintf(1, "PCI: QEMU resource reserve cap not found\n"); + u16 device_id; + + if (pci_config_readw(bdf, PCI_VENDOR_ID) != PCI_VENDOR_ID_REDHAT) { + dprintf(1, "PCI: QEMU resource reserve cap vendor ID doesn't match.\n"); + return 0; + } + + device_id = pci_config_readw(bdf, PCI_DEVICE_ID); + + if (device_id != PCI_DEVICE_ID_REDHAT_ROOT_PORT && + device_id != PCI_DEVICE_ID_REDHAT_BRIDGE) { + dprintf(1, "PCI: QEMU resource reserve cap device ID doesn't match.\n"); + return 0; + } + u8 cap = 0; + + do { + cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, cap); + } while (cap && + pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET) != + REDHAT_CAP_RESOURCE_RESERVE); + if (cap) { + u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS); + if (cap_len < RES_RESERVE_CAP_SIZE) { + dprintf(1, "PCI: QEMU resource reserve cap length %d is invalid\n", + cap_len); + return 0; } - return cap; } else { - dprintf(1, "PCI: QEMU resource reserve cap VID or DID doesn't match.\n"); - return 0; + dprintf(1, "PCI: QEMU resource reserve cap not found\n"); } + return cap; }
/**************************************************************** diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h index 38fa2ca..1096461 100644 --- a/src/hw/pci_ids.h +++ b/src/hw/pci_ids.h @@ -2265,6 +2265,7 @@
#define PCI_VENDOR_ID_REDHAT 0x1b36 #define PCI_DEVICE_ID_REDHAT_ROOT_PORT 0x000C +#define PCI_DEVICE_ID_REDHAT_BRIDGE 0x0001
#define PCI_VENDOR_ID_TEKRAM 0x1de1 #define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29
On 08/13/18 09:49, Jing Liu wrote:
This patch serial is about QEMU resource reserve capability finding in firmware.
Firstly, this fixes a logic bug. When the capability is truncated, return zero instead of the truncated offset. Secondly, this modified the debug messages when the capability is not found and when the vendor ID or device Id doesn't match REDHAT special ones.
Last, this enables the firmware recongizing the REDHAT PCI BRIDGE device ID, so that QEMU can also reserve PCI bridge resource capability.
Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability
src/fw/pciinit.c | 45 ++++++++++++++++++++++++++++----------------- src/hw/pci_ids.h | 1 + 2 files changed, 29 insertions(+), 17 deletions(-)
Something looks wrong with this patch set -- the shortlog above indicates that the 3rd patch is called "pci: recognize RH PCI legacy bridge resource reservation capability", but in the actual series I see:
[SeaBIOS][PATCH v2 0/3] pci: resource reserve capability found [SeaBIOS][PATCH v2 1/3] pci: fix the return value for truncated capability [SeaBIOS][PATCH v2 2/3] pci: clean up the debug message for pci capability found [SeaBIOS][PATCH v2] pci: recognize RH PCI legacy bridge resource
For the last patch, the "3/3" counter is missing in the subject prefix, plus the subject doesn't match the short log.
I also see a separate message
[SeaBIOS] [PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource
which is apparently not threaded under v2 0/3, and whose subject line also doesn't match the shortlog.
Not sure what Kevin and Gerd prefer, but if these patches are meant to form a series, I'd suggest to repost with correct numbering, threading, and subject lines.
Thanks Laszlo
On 8/14/2018 10:01 PM, Laszlo Ersek wrote:
On 08/13/18 09:49, Jing Liu wrote:
This patch serial is about QEMU resource reserve capability finding in firmware.
Firstly, this fixes a logic bug. When the capability is truncated, return zero instead of the truncated offset. Secondly, this modified the debug messages when the capability is not found and when the vendor ID or device Id doesn't match REDHAT special ones.
Last, this enables the firmware recongizing the REDHAT PCI BRIDGE device ID, so that QEMU can also reserve PCI bridge resource capability.
Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability
src/fw/pciinit.c | 45 ++++++++++++++++++++++++++++----------------- src/hw/pci_ids.h | 1 + 2 files changed, 29 insertions(+), 17 deletions(-)
Something looks wrong with this patch set -- the shortlog above indicates that the 3rd patch is called "pci: recognize RH PCI legacy bridge resource reservation capability", but in the actual series I see:
[SeaBIOS][PATCH v2 0/3] pci: resource reserve capability found [SeaBIOS][PATCH v2 1/3] pci: fix the return value for truncated capability [SeaBIOS][PATCH v2 2/3] pci: clean up the debug message for pci capability found [SeaBIOS][PATCH v2] pci: recognize RH PCI legacy bridge resource
For the last patch, the "3/3" counter is missing in the subject prefix, plus the subject doesn't match the short log.
I also see a separate message
[SeaBIOS] [PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource
which is apparently not threaded under v2 0/3, and whose subject line also doesn't match the shortlog.
Not sure what Kevin and Gerd prefer, but if these patches are meant to form a series, I'd suggest to repost with correct numbering, threading, and subject lines.
Let me re-send this serial with the same version. Sorry for disturbing.
Jing
Thanks Laszlo
-
Jing Liu -
Laszlo Ersek -
Liu, Jing2