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(-)
Amazon Development Center Germany GmbH
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Ust-ID: DE 289 237 879
This series implements support for SMBIOS 3.0 entry points in
The main advantage of SMBIOS 3.0 entry points is the higher limit
for total table size. The SMBIOS 2.1 64435 bytes limit can be
easily hit in QEMU if creating virtual machines with more than
Eduardo Habkost (19):
biostables: copy_fseg_table() function
util.h: Delete unused get_smbios_entry_point() prototype
smbios: Rename code specific for SMBIOS 2.1 entry points
smbios: Generic smbios_next() function
smbios: smbios_get_tables() function
smbios: Use smbios_get_tables()/smbios_next() at display_uuid()
smbios: smbios_major_version()/smbios_minor_version() helpers
tpm: Use smbios_get_tables()
csm: Don't check SMBios21Addr before calling copy_smbios_21()
smbios: Make SMBios21Addr variable static
smbios: Use smbios_next() at smbios_romfile_setup()
smbios: Extract SMBIOS table building code to separate function
smbios: Make smbios_build_tables() more generic
smbios: smbios_21_setup_entry_point() function
smbios: Make some smbios_build_tables() arguments optional
smbios: Make smbios_build_tables() ready for 64-bit tables
smbios: copy_smbios_30() function
smbios: Support SMBIOS 3.0 entry point at copy_table()
smbios: Support SMBIOS 3.0 entry point at smbios_romfile_setup()
src/std/smbios.h | 17 ++-
src/util.h | 5 +-
src/fw/biostables.c | 259 +++++++++++++++++++++++++++++++++-----------
src/fw/csm.c | 6 +-
src/fw/smbios.c | 12 +-
src/tcgbios.c | 12 +-
6 files changed, 227 insertions(+), 84 deletions(-)
As an OpenBSD developer I'm very interested in these patches. SeaBIOS is
the only package
left in our ports tree still using lld to link and one of very few ports
not building with Clang. I
just happened to come across your diffs looking to see if anything had
been done in this area
when searching via Google.
This patch series make seabios linkable with lld.
This is beneficial for FreeBSD ports as well
as they can drop an LLD_UNSAFE
As a maintainer of lld ELF, I have triaged numerous pieces of software.
seabios is the only one making use of
This drops the only instance https://sourceware.org/bugzilla/show_bug.cgi?id=12726
1, 2, 3 and 4 are really independent and can be applied in arbitrary order.
5 depends on 4. I originally combined 4 and 5 and that was why I don't think a patch series made sense.
Fangrui Song (5):
romlayout.S: Add missing SHF_ALLOC flag to .fixedaddr.\addr
Make rom16.o linkable with lld
Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf
romlayout32flag.lds: Use `. +=` instead of `. =`
test-build.sh: Delete unneeded LD capability test
Makefile | 4 ++++
scripts/layoutrom.py | 13 ++++++++++---
scripts/test-build.sh | 42 +-----------------------------------------
src/romlayout.S | 2 +-
4 files changed, 16 insertions(+), 45 deletions(-)
Thanks for your reply. Sorry for the delay, was swamped
with other things.
>> Currently I don't know what to recommend, because I
>> don't understand the other side of the INT 13H/14H,
>> only the OS side.
> Well, the other side talks to the hardware,
> and needs drivers to do so. See src/hw
> Surely one can write a serial driver which connects to a remote place
> using some bluetooth protocol instead of talking to a 16550. That'll
> be *alot* of work though, you basically have to implement both
> bluetooth stack and hardware driver.
I expected to assemble, rather than write, such a thing.
If not from the Linux source code, then FreeBSD or
If for some reason (what would that be?) no-one has
abstracted bluetooth to have a clean interface that I
could have trivially reused, then I will put aside my
bluetooth dreams and switch to a different technology.
How about Wifi? Does that exist in a state usable for
>> Sure. For now, I want PDOS/386 to remain traditional.
>> When I have exhausted everything that is possible
>> via the BIOS, I will consider adding UEFI support.
> If you want your firmware provide drivers to you for modern hardware you
> are in a *much* better position with UEFI.
Well, on some/many/most modern machines there is
absolutely no other choice - the BIOS doesn't exist,
even as CSM.
> There is a bluetooth
> protocol specification for example, although I'm not sure how common it
> is to find an actual uefi driver for bluetooth hardware in the firmware.
> Talking to ethernet using the firmware-provided uefi driver shouldn't be
> much of a problem though b/c network boot is a rather standard feature.
Ok, maybe in the medium term I should use a hardware
device, forget the name, that turns ethernet into Wifi.
So then the problem is reduced to me needing to provide
a BOOTX64.EFI that converts INT 14H into UEFI ethernet
>> But I'd like to transport all of that software, designed for
>> that environment, and change nothing at all, and have
>> it work on a new environment that includes Wifi, bluetooth
>> and maybe ethernet, and maybe infrared, and maybe
>> other things I don't know about, but make sense (at
>> some level) to be accessed via INT 14H.
> Well. In the server world it is rather common to provide access to the
> serial line over the network for system management purposes.
> One approach for that is to have a separate management controller (bmc),
> and the serial port of the machine is linked to the management
> controller instead of a D9 socket. You can then connect to the bmc to
> manage the machine, and one of the options available is to get serial
> console access.
Ok, this would allow me to have a BBS.
But not allow me to have a "virtual modem" so that I can
> Another approach is to have a virtual 16550 provided by the firmware.
> Accessing the virtual 16550 will trap into SMM mode where the firmware
> emulates a serial device and allows to access the serial port remotely
> over the network, roughly comparable to how qemu provides an virtual
> 16550 to virtual machines.
Ok, but in the case of qemu I have the same issue - at the end
of the day I want to drive a modem, so with qemu I can get it
to talk to a "virtual modem". If the firmware is providing the
serial to network conversion, I also need to stick in a virtual
modem there. And that's what I was hoping SeaBIOS would
allow me to do.
> Note that both approaches work at hardware level not int14h level,
> because modern operating systems use int14h services in bootloaders
> only if at all.
My operating system, PDOS/386, may not be considered "modern",
even though it is in active development, but I do wish to use
INT 14H, as that was the traditional BIOS service provided, and I
wish to maintain contact with the original 80386 machines.
I expect a modern environment to have the CPU, memory etc
required to support this basic interface.