Re: [SeaBIOS] >256 Virtio-net-pci hotplug Devices

So as it turns out at 512 devices, it is nothing to do SeaBIOS, it was the Kernel again. It is taking quite a while to startup, a little over two hours (7489 seconds). The main culprits appear to be enumerating/initializing the PCI Express ports and enabling interrupts. The PCI Express Root

Re: [SeaBIOS] >256 Virtio-net-pci hotplug Devices

On Sun, Jul 23, 2017 at 07:28:01PM +0300, Marcel Apfelbaum wrote: > On 22/07/2017 2:57, Kinsella, Ray wrote: > > When scaling up to 512 Virtio-net devices SeaBIOS appears to really slow > > down when configuring PCI Config space - haven't manage to get this to > > work yet. If there is a slowdown

Re: [SeaBIOS] [RFC PATCH v2 4/4] pci: enable RedHat PCI bridges to reserve additional buses on PCI init

By the way, any ideas on how to avoid 'bus overstealing' would be greatly appreciated. Static BIOS variable isn't applicable since its value isn't saved across reboots. 2017-07-23 19:43 GMT+03:00 Alexander Bezzubikov : > 2017-07-23 5:49 GMT+03:00 Michael S. Tsirkin

Re: [SeaBIOS] [RFC PATCH v2 2/6] hw/i386: allow SHPC for Q35 machine

2017-07-23 18:59 GMT+03:00 Marcel Apfelbaum : > On 23/07/2017 1:15, Aleksandr Bezzubikov wrote: > >> Unmask previously masked SHPC feature in _OSC method. >> >> Signed-off-by: Aleksandr Bezzubikov >> --- >> hw/i386/acpi-build.c | 2 +- >> 1 file changed,

Re: [SeaBIOS] [RFC PATCH v2 3/4] pci: add QEMU-specific PCI capability structure

2017-07-23 19:30 GMT+03:00 Kevin O'Connor : > On Sun, Jul 23, 2017 at 01:11:49AM +0300, Aleksandr Bezzubikov wrote: > > On PCI init PCI bridge devices may need some > > extra info about bus number to reserve, IO, memory and > > prefetchable memory limits. QEMU can provide this

Re: [SeaBIOS] [RFC PATCH v2 4/4] pci: enable RedHat PCI bridges to reserve additional buses on PCI init

2017-07-23 5:49 GMT+03:00 Michael S. Tsirkin : > On Sun, Jul 23, 2017 at 01:11:50AM +0300, Aleksandr Bezzubikov wrote: > > In case of Red Hat PCI bridges reserve additional buses, which number is > provided > > in a vendor-specific capability. > > > > Signed-off-by: Aleksandr

Re: [SeaBIOS] [RFC PATCH v2 3/4] pci: add QEMU-specific PCI capability structure

On Sun, Jul 23, 2017 at 01:11:49AM +0300, Aleksandr Bezzubikov wrote: > On PCI init PCI bridge devices may need some > extra info about bus number to reserve, IO, memory and > prefetchable memory limits. QEMU can provide this > with special vendor-specific PCI capability. > > This capability is

Re: [SeaBIOS] >256 Virtio-net-pci hotplug Devices

On 22/07/2017 2:57, Kinsella, Ray wrote: Hi Marcel Hi Ray, On 21/07/2017 01:33, Marcel Apfelbaum wrote: On 20/07/2017 3:44, Kinsella, Ray wrote: That's strange. Please ensure the virtio devices are working in virtio 1.0 mode (disable-modern=0,disable-legacy=1). Let us know any problems

Re: [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware

On 23/07/2017 19:19, Alexander Bezzubikov wrote: 2017-07-23 18:57 GMT+03:00 Marcel Apfelbaum >: On 23/07/2017 1:15, Aleksandr Bezzubikov wrote: On PCI init PCI bridges may need some extra info about bus number to reserve, IO,

Re: [SeaBIOS] [RFC PATCH v2 1/4] pci: refactor pci_find_capapibilty to get bdf as the first argument instead of the whole pci_device

On Sun, Jul 23, 2017 at 01:11:47AM +0300, Aleksandr Bezzubikov wrote: > Refactor pci_find_capability function to get bdf instead of > a whole pci_device* as the only necessary field for this function > is still bdf. > It greatly helps when we have bdf but not pci_device. > > Signed-off-by:

Re: [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware

2017-07-23 18:57 GMT+03:00 Marcel Apfelbaum : > On 23/07/2017 1:15, Aleksandr Bezzubikov wrote: > >> On PCI init PCI bridges may need some >> extra info about bus number to reserve, IO, memory and >> prefetchable memory limits. QEMU can provide this >> with special

Re: [SeaBIOS] [RFC PATCH v2 2/4] pci: add RedHat vendor ID

On 23/07/2017 1:11, Aleksandr Bezzubikov wrote: Signed-off-by: Aleksandr Bezzubikov --- src/hw/pci_ids.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h index 4ac73b4..db2e694 100644 --- a/src/hw/pci_ids.h +++ b/src/hw/pci_ids.h

Re: [SeaBIOS] [RFC PATCH v2 1/4] pci: refactor pci_find_capapibilty to get bdf as the first argument instead of the whole pci_device

Hi Alexandr, On 23/07/2017 1:11, Aleksandr Bezzubikov wrote: Refactor pci_find_capability function to get bdf instead of a whole pci_device* as the only necessary field for this function is still bdf. It greatly helps when we have bdf but not pci_device. You can drop the last sentence. Other

Re: [SeaBIOS] [RFC PATCH v2 2/6] hw/i386: allow SHPC for Q35 machine

On 23/07/2017 1:15, Aleksandr Bezzubikov wrote: Unmask previously masked SHPC feature in _OSC method. Signed-off-by: Aleksandr Bezzubikov --- hw/i386/acpi-build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/i386/acpi-build.c

Re: [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware

On 23/07/2017 1:15, Aleksandr Bezzubikov wrote: On PCI init PCI bridges may need some extra info about bus number to reserve, IO, memory and prefetchable memory limits. QEMU can provide this with special vendor-specific PCI capability. Sizes of limits match ones from PCI Type 1 Configuration

Re: [SeaBIOS] [RFC PATCH v2 5/6] hw/pci: add bus_reserve property to pcie-root-port

On 23/07/2017 15:22, Michael S. Tsirkin wrote: On Sun, Jul 23, 2017 at 01:15:42AM +0300, Aleksandr Bezzubikov wrote: To enable hotplugging of a newly created pcie-pci-bridge, we need to tell firmware (SeaBIOS in this case) Hi Michael, Presumably, EFI would need to support this too?

Re: [SeaBIOS] [RFC PATCH v2 5/6] hw/pci: add bus_reserve property to pcie-root-port

On Sun, Jul 23, 2017 at 01:15:42AM +0300, Aleksandr Bezzubikov wrote: > To enable hotplugging of a newly created pcie-pci-bridge, > we need to tell firmware (SeaBIOS in this case) Presumably, EFI would need to support this too? > to reserve > additional buses for pcie-root-port, that allows us