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
--
1.8.3.1
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
Hi Zihan,
I copy your comments of this patch several days ago here,
and hope we could continue some discussion in this serial.
On 8/16/2018 10:32 AM, Jing Liu wrote:
[...]
>
> 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) {
======= comments by Zihan Yang =========
I think PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE shoud be added too, in case we put
a pcie_pci_bridge at the host bus.
========================================
My reply:
In theory all the pci bridge could add this capability but I'm not sure
if we really need that? Would like to hear some more suggestion!
Thanks,
Jing
[...]
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
Liu, Jing2 <jing2.liu@linux.intel.com> 于2018年8月16日周四 上午10:39写道：
>
> Hi Zihan,
>
> I copy your comments of this patch several days ago here,
> and hope we could continue some discussion in this serial.
Hi Jing,
Sorry for the delay. I tested at the code just now and find that pcie
bridge does not
use a vendor specific capability. I met this warning in another
ongoing patch so I just
added pcie bridge to suppress the warning.
Now that it turns out pcie bridge does not use this vendor specific
capability, I think you
might want to stick with your original patch, and add it in the future
when redhat decides
to add specific capabilities in pcie bridge. I'm not quite an expert
in this field, so unfortunately
I don't have much insights to give, but I'm open for a discussion.
> On 8/16/2018 10:32 AM, Jing Liu wrote:
> [...]
> >
> > 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) {
>
> ======= comments by Zihan Yang =========
> I think PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE shoud be added too, in case we put
> a pcie_pci_bridge at the host bus.
> ========================================
> My reply:
> In theory all the pci bridge could add this capability but I'm not sure
> if we really need that? Would like to hear some more suggestion!
>
>
> Thanks,
> Jing
>
> [...]
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
On 8/16/2018 1:06 PM, Zihan Yang wrote: > Liu, Jing2 <jing2.liu@linux.intel.com> 于2018年8月16日周四 上午10:39写道： >> >> Hi Zihan, >> >> I copy your comments of this patch several days ago here, >> and hope we could continue some discussion in this serial. > > Hi Jing, > > Sorry for the delay. I tested at the code just now and find that pcie > bridge does not > use a vendor specific capability. I met this warning in another > ongoing patch so I just > added pcie bridge to suppress the warning. > > Now that it turns out pcie bridge does not use this vendor specific > capability, I think you > might want to stick with your original patch, and add it in the future > when redhat decides > to add specific capabilities in pcie bridge. Yes, I agree. I'm not quite an expert > in this field, so unfortunately > I don't have much insights to give, but I'm open for a discussion. > Thanks, Jing _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
Hi, > I think PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE shoud be added too, in case we put > a pcie_pci_bridge at the host bus. Yes, please. thanks, Gerd _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
Hi Gerd, On 8/16/2018 3:19 PM, Gerd Hoffmann wrote: > Hi, > >> I think PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE shoud be added too, in case we put >> a pcie_pci_bridge at the host bus. > > Yes, please. Thanks for comments. Sure, can be added simply. While this bridge doesn't have resource reserve capability in qemu now. Do we really need this for now? Thanks Jing > > thanks, > Gerd > _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
On Thu, Aug 16, 2018 at 05:30:45PM +0800, Liu, Jing2 wrote: > Hi Gerd, > > On 8/16/2018 3:19 PM, Gerd Hoffmann wrote: > > Hi, > > > > > I think PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE shoud be added too, in case we put > > > a pcie_pci_bridge at the host bus. > > > > Yes, please. > Thanks for comments. Sure, can be added simply. While this bridge doesn't > have resource reserve capability in qemu now. Do we really need this for > now? No. I assumed all bridges have that without actually checking. So this can wait until qemu added the options. Once the refactoring is done whitelisting more bridges is a simple two-line patch. cheers, Gerd _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
On 8/16/2018 9:10 PM, Gerd Hoffmann wrote: > On Thu, Aug 16, 2018 at 05:30:45PM +0800, Liu, Jing2 wrote: >> Hi Gerd, >> >> On 8/16/2018 3:19 PM, Gerd Hoffmann wrote: >>> Hi, >>> >>>> I think PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE shoud be added too, in case we put >>>> a pcie_pci_bridge at the host bus. >>> >>> Yes, please. >> Thanks for comments. Sure, can be added simply. While this bridge doesn't >> have resource reserve capability in qemu now. Do we really need this for >> now? > > No. I assumed all bridges have that without actually checking. So this > can wait until qemu added the options. OK, so let's just keep the patch and add the support for other bridges until qemu has this capability in the future, right? > Once the refactoring is done > whitelisting more bridges is a simple two-line patch. Yes, I agree. Thanks, Jing > > cheers, > Gerd > _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
Hi,
> + 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");
I'd suggest to use a higher debug level for this one, 3 would be a good
pick I think. level 1 messages are printed by default, and we should
not spam the log just because there is a non-qemu bridge present in the
system.
cheers,
Gerd
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
> Hi,
>
>> + 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");
>
> I'd suggest to use a higher debug level for this one, 3 would be a good
> pick I think. level 1 messages are printed by default, and we should
> not spam the log just because there is a non-qemu bridge present in the
> system.
OK. Will do that.
Jing
>
> cheers,
> Gerd
>
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
On 08/16/18 12:43, Liu, Jing2 wrote:
>
>
> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
>> Hi,
>>
>>> + 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");
>>
>> I'd suggest to use a higher debug level for this one, 3 would be a good
>> pick I think. level 1 messages are printed by default, and we should
>> not spam the log just because there is a non-qemu bridge present in the
>> system.
> OK. Will do that.
With the debug level update, I'm ready to give my R-b for this series.
Thanks,
Laszlo
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
Hi Laszlo,
On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
> On 08/16/18 12:43, Liu, Jing2 wrote:
>>
>>
>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
>>> Hi,
>>>
>>>> + 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");
>>>
>>> I'd suggest to use a higher debug level for this one, 3 would be a good
>>> pick I think. level 1 messages are printed by default, and we should
>>> not spam the log just because there is a non-qemu bridge present in the
>>> system.
>> OK. Will do that.
>
> With the debug level update, I'm ready to give my R-b for this series.
>
Thanks for your feedback!
So do I need update another version and with your R-b?
Thanks,
Jing
> Thanks,
> Laszlo
>
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
On 08/24/18 04:23, Liu, Jing2 wrote:
> Hi Laszlo,
>
> On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
>> On 08/16/18 12:43, Liu, Jing2 wrote:
>>>
>>>
>>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
>>>> Hi,
>>>>
>>>>> + 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");
>>>>
>>>> I'd suggest to use a higher debug level for this one, 3 would be a good
>>>> pick I think. level 1 messages are printed by default, and we should
>>>> not spam the log just because there is a non-qemu bridge present in the
>>>> system.
>>> OK. Will do that.
>>
>> With the debug level update, I'm ready to give my R-b for this series.
>>
> Thanks for your feedback!
> So do I need update another version and with your R-b?
I imagine you'd post v3 with the update Gerd requested for the debug
level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS
maintainer so that'll not be "decisive" by any means.)
Thanks
Laszlo
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
On 8/24/2018 3:12 PM, Laszlo Ersek wrote:
> On 08/24/18 04:23, Liu, Jing2 wrote:
>> Hi Laszlo,
>>
>> On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
>>> On 08/16/18 12:43, Liu, Jing2 wrote:
>>>>
>>>>
>>>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
>>>>> Hi,
>>>>>
>>>>>> + 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");
>>>>>
>>>>> I'd suggest to use a higher debug level for this one, 3 would be a good
>>>>> pick I think. level 1 messages are printed by default, and we should
>>>>> not spam the log just because there is a non-qemu bridge present in the
>>>>> system.
>>>> OK. Will do that.
>>>
>>> With the debug level update, I'm ready to give my R-b for this series.
>>>
>> Thanks for your feedback!
>> So do I need update another version and with your R-b?
>
> I imagine you'd post v3 with the update Gerd requested for the debug
> level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS
> maintainer so that'll not be "decisive" by any means.)
>
Got it. Will send later!
Thanks,
Jing
> Thanks
> Laszlo
>
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
On 8/24/2018 3:12 PM, Laszlo Ersek wrote:
> On 08/24/18 04:23, Liu, Jing2 wrote:
>> Hi Laszlo,
>>
>> On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
>>> On 08/16/18 12:43, Liu, Jing2 wrote:
>>>>
>>>>
>>>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
>>>>> Hi,
>>>>>
>>>>>> + 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");
>>>>>
>>>>> I'd suggest to use a higher debug level for this one, 3 would be a good
>>>>> pick I think. level 1 messages are printed by default, and we should
>>>>> not spam the log just because there is a non-qemu bridge present in the
>>>>> system.
>>>> OK. Will do that.
>>>
>>> With the debug level update, I'm ready to give my R-b for this series.
>>>
>> Thanks for your feedback!
>> So do I need update another version and with your R-b?
>
> I imagine you'd post v3 with the update Gerd requested for the debug
> level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS
> maintainer so that'll not be "decisive" by any means.)
>
Oh, BTW, I am considering, if only dismatch vendor-id stands for
"non-qemu bridge" or dismatch both vid and did? I guess I need change both.
Thanks,
Jing
> Thanks
> Laszlo
>
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
On 08/24/18 09:48, Liu, Jing2 wrote:
>
>
> On 8/24/2018 3:12 PM, Laszlo Ersek wrote:
>> On 08/24/18 04:23, Liu, Jing2 wrote:
>>> Hi Laszlo,
>>>
>>> On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
>>>> On 08/16/18 12:43, Liu, Jing2 wrote:
>>>>>
>>>>>
>>>>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>>> + 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");
>>>>>>
>>>>>> I'd suggest to use a higher debug level for this one, 3 would be a
>>>>>> good
>>>>>> pick I think. level 1 messages are printed by default, and we should
>>>>>> not spam the log just because there is a non-qemu bridge present
>>>>>> in the
>>>>>> system.
>>>>> OK. Will do that.
>>>>
>>>> With the debug level update, I'm ready to give my R-b for this series.
>>>>
>>> Thanks for your feedback!
>>> So do I need update another version and with your R-b?
>>
>> I imagine you'd post v3 with the update Gerd requested for the debug
>> level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS
>> maintainer so that'll not be "decisive" by any means.)
>>
> Oh, BTW, I am considering, if only dismatch vendor-id stands for
> "non-qemu bridge" or dismatch both vid and did? I guess I need change both.
I don't understand. Can you post an incremental diff in this thread just
for illustration?
Thanks
Laszlo
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
On 8/24/2018 4:02 PM, Laszlo Ersek wrote:
> On 08/24/18 09:48, Liu, Jing2 wrote:
[...]
>>>>>>>> + 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");
>>>>>>>
>>>>>>> I'd suggest to use a higher debug level for this one, 3 would be a
>>>>>>> good
>>>>>>> pick I think. level 1 messages are printed by default, and we should
>>>>>>> not spam the log just because there is a non-qemu bridge present
>>>>>>> in the
>>>>>>> system.
>>>>>> OK. Will do that.
>>>>>
>>>>> With the debug level update, I'm ready to give my R-b for this series.
>>>>>
>>>> Thanks for your feedback!
>>>> So do I need update another version and with your R-b?
>>>
>>> I imagine you'd post v3 with the update Gerd requested for the debug
>>> level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS
>>> maintainer so that'll not be "decisive" by any means.)
>>>
>> Oh, BTW, I am considering, if only dismatch vendor-id stands for
>> "non-qemu bridge" or dismatch both vid and did? I guess I need change both.
>
> I don't understand. Can you post an incremental diff in this thread just
> for illustration?
We check vendor-id/device-id and report when dismatch.
My question is,
Gerd suggested "not spam the log just because there is a non-qemu bridge
present", so I think if both vendor-id and device-id dismatch means
non-qemu bridge present?
+ if (pci_config_readw(bdf, PCI_VENDOR_ID) != PCI_VENDOR_ID_REDHAT) {
+ dprintf(3, "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(3, "PCI: QEMU resource reserve cap device ID doesn't
match.\n");
+ return 0;
+ }
>
> Thanks
> Laszlo
>
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
> > I imagine you'd post v3 with the update Gerd requested for the debug > > level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS > > maintainer so that'll not be "decisive" by any means.) > > > Oh, BTW, I am considering, if only dismatch vendor-id stands for > "non-qemu bridge" or dismatch both vid and did? I guess I need change both. Yes, only the vendor id. If you found a pci bridge with redhat vendor id you know it's qemu. cheers, Gerd _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
Hi Gerd, On 8/24/2018 4:24 PM, Gerd Hoffmann wrote: >>> I imagine you'd post v3 with the update Gerd requested for the debug >>> level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS >>> maintainer so that'll not be "decisive" by any means.) >>> >> Oh, BTW, I am considering, if only dismatch vendor-id stands for >> "non-qemu bridge" or dismatch both vid and did? I guess I need change both. > > Yes, only the vendor id. If you found a pci bridge with redhat vendor > id you know it's qemu. Oh, got it! Thanks Gerd! Will send v3 later. Jing > > cheers, > Gerd > _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
On Fri, Aug 24, 2018 at 09:12:47AM +0200, Laszlo Ersek wrote:
> On 08/24/18 04:23, Liu, Jing2 wrote:
> > Hi Laszlo,
> >
> > On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
> >> On 08/16/18 12:43, Liu, Jing2 wrote:
> >>>
> >>>
> >>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
> >>>> Hi,
> >>>>
> >>>>> + 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");
> >>>>
> >>>> I'd suggest to use a higher debug level for this one, 3 would be a good
> >>>> pick I think. level 1 messages are printed by default, and we should
> >>>> not spam the log just because there is a non-qemu bridge present in the
> >>>> system.
> >>> OK. Will do that.
> >>
> >> With the debug level update, I'm ready to give my R-b for this series.
> >>
> > Thanks for your feedback!
> > So do I need update another version and with your R-b?
>
> I imagine you'd post v3 with the update Gerd requested for the debug
> level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS
> maintainer so that'll not be "decisive" by any means.)
Yep, I've expected you post a v3 with the debug level change (whole
series).
cheers,
Gerd
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
© 2016 - 2025 Red Hat, Inc.