While looking at VM bootup times, we stumbled over the fact that the NVMe
code only does I/O operations of up to 4kb at a given point in time. This
is usually ok, but if you have an OS that loads a lot of data on boot in
combination to network backed storage, it shows in bootup times.
There is no need to restrict ourselves to 4kb though. The INT13 call we
receive gives us much larger chunks which we can just map into a native
bigger NVMe I/O call if the request buffer is page aligned.
This patch implements all logic required to do the above and gives a
substantial performance boost on boot.
v1 -> v2:
- fix dprintf
- Fix bounds check on PRP list add logic
- Reduce PRP list to 15 entries embedded in the ns struct.
This reduces BIOS reserved memory footprint by 4kb.
v2 -> v3:
- new patch: nvme: Split requests by maximum allowed size
- Adjust the maximum request size to sector units. The hardware field
describes it in pages.
Alexander Graf (4):
nvme: Record maximum allowed request size
nvme: Allow to set PRP2
nvme: Pass large I/O requests as PRP lists
nvme: Split requests by maximum allowed size
src/hw/nvme-int.h | 16 ++++++-
src/hw/nvme.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 121 insertions(+), 17 deletions(-)
--
2.16.4
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
Hi,
It's been a while since the last release, we have some nice but
unreleased bits in the master branch (tpm and nvme improvements
for example), time for a new release I think.
How about freeze in a week, release by roughly mid-november?
take care,
Gerd
Hi all,
(All was done with SeaBIOS 1.15.0)
I was testing a coreboot change when suddenly both of my two P2B-LS
boards failed to boot. I have been booting off a Maxtor 6E040L0 hard
drive when the boot started to stall after SeaBIOS. Took me hours but
eventually I found a line in my serial log that there has been a DMA
timeout. I had to turn UDMA off from coreboot to resolve. I landed a
patch there to enable UDMA on all 4 drives by default, thinking it was
the reasonable thing to do and should have worked. Does SeaBIOS manage
or enable UDMA itself? Is there more to UDMA than just enable it in
PIIX4?
And while I'm troubleshooting the boot, I plugged in a Promise SATA150
tx2plus card and moved the hard drive there. SeaBIOS caught and and
ran its option ROM just fine, but didn't bother booting from it,
instead going to the iPXE ROM I managed to insert after freeing enough
space in the flash image. Why?
Thanks
Keith
if driver reads data larger than VIRTIO_BLK_F_SIZE_MAX, it will cause
some issue to the DMA engine.
So add VIRTIO_BLK_F_SIZE_MAX feature support, when upper software
wants to read data larger than VIRTIO_BLK_F_SIZE_MAX, virtio-blk
driver split one large request into multiple smaller ones.
Andy Pei (3):
virtio-blk: add feature VIRTIO_BLK_F_SIZE_MAX and VIRTIO_BLK_F_SEG_MAX
virtio-blk: abstract a function named virtio_blk_op_one_segment to
handle r/w request
virtio-blk.: split large IO according to size_max
src/block.h | 2 +
src/hw/virtio-blk.c | 128 +++++++++++++++++++++++++++++++++++++++++-----------
src/hw/virtio-blk.h | 3 ++
3 files changed, 107 insertions(+), 26 deletions(-)
--
1.8.3.1
Some versions of gcc complain when VAR16 is used in both the header
and C files - use only in the C file to fix the warning.
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
vgasrc/svgamodes.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/vgasrc/svgamodes.h b/vgasrc/svgamodes.h
index 782d30b..6ac1d64 100644
--- a/vgasrc/svgamodes.h
+++ b/vgasrc/svgamodes.h
@@ -6,7 +6,7 @@ struct generic_svga_mode {
struct vgamode_s info;
};
-extern struct generic_svga_mode svga_modes[] VAR16;
-extern unsigned int svga_mcount VAR16;
+extern struct generic_svga_mode svga_modes[];
+extern unsigned int svga_mcount;
#endif /* __SVGAMODES_H */
--
2.31.1
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.
Patch [1/2] fixes main issue by treating the bridge as a device with
possible SHPC capability.
Patch [2/2] fixes missed IO reservation, by making sure that in the case of
the bridge firmware reserves IO resource.
Igor Mammedov (2):
pci: reserve resources for pcie-pci-bridge to fix regressed hotplug on
q35
pci: let firmware reserve IO for pcie-pci-bridge
src/fw/pciinit.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
--
2.27.0