[SeaBIOS] Re: new november release?
On Tue, Nov 23, 2021 at 09:50:44AM +0100, Gerd Hoffmann wrote: > Hi, > > > > Damn. Support for smbiod 3.0 fall completely through the cracks: > > > > > > https://www.mail-archive.com/seabios@seabios.org/msg12438.html > > > > > > The qemu-side changes have long been merged (except for flipping the > > > default to 3.0), but I didn't pay attention so the seabios patches > > > didn't got merged :( > > > > > > I'd live to have them included in the new release, I suspect that > > > implies we have to extend the freeze and release in early december? > > > > Yeah - if we're going to make a change now, I think we should wait a > > few weeks before tagging a release. > > > > It's been a while since I've looked at the smbios 3 patches - are > > there any changes since then? > > Latest version is at: > https://gitlab.com/ehabkost/seabios/-/commits/work/smbios-3.0/ > > Rebased, but no functional changes in the smbios updates. I took another look at those patches and they look fine to me. I'm not sure what you'd prefer to do with the SeaBIOS release though. We have a couple of high-level options: 1. Release v1.15.0 this week without these changes (tag 64f37cc5). 2. Commit the smbios 3 changes (and pcie-pci-bridge changes) and release v1.15.0 in early January. I suppose we could commit the changes and try to make a release in December, but that seems like it would dilute the meaning of a "release". What are your thoughts? Cheers, -Kevin ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 2/2] pci: let firmware reserve IO for pcie-pci-bridge
Igor Mammedov wrote: > +++ b/src/fw/pciinit.c .. > @@ -819,12 +825,13 @@ static int pci_bus_hotplug_support(struct pci_bus *bus, > u8 pcie_cap) > */ > u16 slot_implemented = pcie_flags & PCI_EXP_FLAGS_SLOT; > > -return downstream_port && slot_implemented; > +return downstream_port && slot_implemented ? > +HOTPLUG_PCIE : HOTPLUG_NO_SUPPORTED; > } > > check_shpc: > shpc_cap = pci_find_capability(bus->bus_dev->bdf, PCI_CAP_ID_SHPC, 0); > -return !!shpc_cap; > +return !!shpc_cap ? HOTPLUG_SHPC : HOTPLUG_NO_SUPPORTED; Maybe remove !! here. //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 0/2] pci: reserve resources for pcie-pci-bridge to fix regressed hotplug on q35 with ACPI hotplug enabled
On Mon, Nov 29, 2021 at 06:48:10AM -0500, Igor Mammedov wrote: > Since QEMU-6.1, Q35 machine is using ACPI PCI hotplug by default. > However SeaBIOS did not take in account pcie-pci-bridge and treated it > as any other PCIe device which is not correct in the case of the bridge. Thanks. It looks fine to me. I'll give another day or so for others to comment, but otherwise will plan to commit. -Kevin ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 2/2] pci: let firmware reserve IO for pcie-pci-bridge
On 29/11/2021 12:48, Igor Mammedov wrote:
With [1] patch hotplug of rtl8139 succeeds, with caveat that it
fails to initialize IO bar, which is caused by [2] that makes
firmware skip IO reservation for any PCIe device, which isn't
correct in case of pcie-pci-bridge.
Fix it by exposing hotplug type and making IO resource optional
only if PCIe hotplug is in use.
[1]
"pci: reserve resources for pcie-pci-bridge to fix regressed hotplug on q35"
[2]
Fixes: 76327b9f32a ("fw/pci: do not automatically allocate IO region for PCIe
bridges")
Signed-off-by: Igor Mammedov imamm...@redhat.com
CC: mapfe...@redhat.com
CC: kra...@redhat.com
CC: m...@redhat.com
CC: lviv...@redhat.com
CC: jus...@redhat.com
---
src/fw/pciinit.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 7342d8d8..badf13d3 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -793,7 +793,13 @@ pci_region_create_entry(struct pci_bus *bus, struct
pci_device *dev,
return entry;
}
-static int pci_bus_hotplug_support(struct pci_bus *bus, u8 pcie_cap)
+typedef enum hotplug_type_t {
+HOTPLUG_NO_SUPPORTED = 0,
+HOTPLUG_PCIE,
+HOTPLUG_SHPC
+} hotplug_type_t;
+
+static hotplug_type_t pci_bus_hotplug_support(struct pci_bus *bus, u8 pcie_cap)
{
u8 shpc_cap;
@@ -819,12 +825,13 @@ static int pci_bus_hotplug_support(struct pci_bus *bus, u8 pcie_cap)
*/
u16 slot_implemented = pcie_flags & PCI_EXP_FLAGS_SLOT;
-return downstream_port && slot_implemented;
+return downstream_port && slot_implemented ?
+HOTPLUG_PCIE : HOTPLUG_NO_SUPPORTED;
}
check_shpc:
shpc_cap = pci_find_capability(bus->bus_dev->bdf, PCI_CAP_ID_SHPC, 0);
-return !!shpc_cap;
+return !!shpc_cap ? HOTPLUG_SHPC : HOTPLUG_NO_SUPPORTED;
}
/* Test whether bridge support forwarding of transactions
@@ -909,7 +916,7 @@ static int pci_bios_check_devices(struct pci_bus *busses)
u8 pcie_cap = pci_find_capability(bdf, PCI_CAP_ID_EXP, 0);
u8 qemu_cap = pci_find_resource_reserve_capability(bdf);
-int hotplug_support = pci_bus_hotplug_support(s, pcie_cap);
+hotplug_type_t hotplug_support = pci_bus_hotplug_support(s, pcie_cap);
for (type = 0; type < PCI_REGION_TYPE_COUNT; type++) {
u64 align = (type == PCI_REGION_TYPE_IO) ?
PCI_BRIDGE_IO_MIN : PCI_BRIDGE_MEM_MIN;
@@ -953,7 +960,9 @@ static int pci_bios_check_devices(struct pci_bus *busses)
if (pci_region_align(>r[type]) > align)
align = pci_region_align(>r[type]);
u64 sum = pci_region_sum(>r[type]);
-int resource_optional = pcie_cap && (type == PCI_REGION_TYPE_IO);
+int resource_optional = 0;
+if (hotplug_support == HOTPLUG_PCIE)
+resource_optional = pcie_cap && (type == PCI_REGION_TYPE_IO);
if (!sum && hotplug_support && !resource_optional)
sum = align; /* reserve min size for hot-plug */
if (size > sum) {
Tested-by: Laurent Vivier
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2] src/hw/virtio-blk: add feature VIRTIO_BLK_F_SIZE_MAX and VIRTIO_BLK_F_SEG_MAX
On Tue, Nov 30, 2021 at 05:23:52AM +, Pei, Andy wrote: > Hi Gerd, > > Yes, you are right. > I think reading these two config register is fine during init and align with > the virtio blk spec. It is not wrong but also pointless. > In the near future, we will working on some related work on these two value. > To be specific, we will do some modification in virtio blk driver. If driver > reads data larger than VIRTIO_BLK_F_SIZE_MAX, > it will cause some issue to the DMA engine. Please submit all changes together as patch series. thanks, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
