SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH 0/2] Allow RedHat PCI bridges reserve more buses than necessary during init
by Konrad Rzeszutek Wilk 20 Jul '17

20 Jul '17

On Wed, Jul 19, 2017 at 05:14:41PM +0000, Alexander Bezzubikov wrote: > ср, 19 июля 2017 г. в 16:57, Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>: > > > On Wed, Jul 19, 2017 at 04:20:12PM +0300, Aleksandr Bezzubikov wrote: > > > Now PCI bridges (and PCIE root port too) get a bus range number in > > system init, > > > basing on currently plugged devices. That's why when one wants to > > hotplug another bridge, > > > it needs his child bus, which the parent is unable to provide. > > > > Could you explain how you trigger this? > > > I'm trying to hot plug pcie-pci bridge into pcie root port, and Linux says > 'cannot allocate bus number for device bla-bla'. This obviously does not > allow me to use the bridge at all. > > > > > > > > The suggested workaround is to have vendor-specific capability in RedHat > > generic pcie-root-port > > > that contains number of additional bus to reserve on BIOS PCI init. > > > > But wouldn't the proper fix be for the PCI bridge to have the subordinate > > value be extended to fit more bus ranges? > > > What do you mean? This is what I'm trying to do. Do you suppose to get rid > of vendor-specific cap and use original register value instead of it? I would suggest a simple fix - each bridge has a a number of bus devices it can use. You have up to 255 - so you split the number of northbridge numbers by the amount of NUMA nodes (if that is used) - so for example if you have 4 NUMA nodes, each bridge would cover 63 bus numbers. Meaning the root bridge would cover 0->63 bus, 64->128, and so on. That gives you enough space to plug in your plugged in devices (up to 63). And if you need sub-briges then carve out a specific range. > > > > > > > > > Aleksandr Bezzubikov (2): > > > pci: add support for direct usage of bdf for capability lookup > > > pci: enable RedHat pci bridges to reserve more buses > > > > > > src/fw/pciinit.c | 12 ++++++++++-- > > > src/hw/pcidevice.c | 24 ++++++++++++++++++++++++ > > > src/hw/pcidevice.h | 1 + > > > 3 files changed, 35 insertions(+), 2 deletions(-) > > > > > > -- > > > 2.7.4 > > > > > > > > > -- > Alexander Bezzubikov

1 0

Re: [SeaBIOS] [Qemu-devel] [Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xiao Guangrong 17 Jul '17

17 Jul '17

On 07/17/2017 03:34 PM, Xulei (Stone) wrote: > > On 07/17/2017 11:13 AM, Xulei (Stone) wrote: > > >> |--virtio_queue_empty > >> > >> Then, kmod falls in infinite loop in handle EPT_MISCONFIG. > >> As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return > >> from mmio write and wait for virtio backend(qemu) to handle this mmio writing. > >> What puzzles me: > >> 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. > > >From the trace in L1 guest, it did not hang in KVM, as it went into guest mode normally. > > >> 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related > >> with vmware? > >> > > > It is the issue in vmware, i guess the RIP register is not handled correctly. > > BTW, does kvm unit tests run well on nested vmware? > > Sadly, kvm unit tests run fail on nested vmware and make the CentOS 7.3(with kmod 4.4.11) crashed... > Well, so that should be reported to vmware. :-)

1 0

Re: [SeaBIOS] [Qemu-devel] [Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xiao Guangrong 17 Jul '17

17 Jul '17

On 07/17/2017 11:13 AM, Xulei (Stone) wrote: > |--virtio_queue_empty > > Then, kmod falls in infinite loop in handle EPT_MISCONFIG. > As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return > from mmio write and wait for virtio backend(qemu) to handle this mmio writing. > What puzzles me: > 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. From the trace in L1 guest, it did not hang in KVM, as it went into guest mode normally. > 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related > with vmware? > It is the issue in vmware, i guess the RIP register is not handled correctly. BTW, does kvm unit tests run well on nested vmware?

2 1

[Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xulei (Stone) 17 Jul '17

17 Jul '17

Hello all, Recently, I met a werid question when i run a VM in the following platfrom: Vmware Vsphere 6.0/6.5 |-- centos 7.3 nested VM (with qemu 2.8, kmod 4.4.11, seabios 1.10) |-- VM (with virtio-scsi controller, modern mode) VM MUST hang in seabios when try to mmio write during virtio-scsi init. I deeply analyze the code, and i found that: Seabios calltrace: scsi_drive_setup |-- cdb_get_inquiry |-- virtio_scsi_process_op |-- vring_kick |-- writew (hang here, mmio write, never return...) Kmod calltrace: handle_EPT_MISCONFIG |--kvm_io_bus_write |-- kvm_iodevice_write (fast mmio through ioeventfd to trigger qemu) |-- vcpu_run |-- vcpu_enter_guest Qemu calltrace: os_host_main_loop_wait |--glib_pollfds_poll |-- aio_dispatch |-- vritio_scsi_handle_cmd_vq |--virtio_scsi_pop_req |-- virtqueue_pop |--virtio_queue_empty Then, kmod falls in infinite loop in handle EPT_MISCONFIG. As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return from mmio write and wait for virtio backend(qemu) to handle this mmio writing. What puzzles me: 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related with vmware? Looking forward for directions... Attached Kmod ftrace: CPU 0/KVM-9435 [008] .... 241968.479572: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479573: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479573: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479583: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479589: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479589: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479599: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479600: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479601: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479610: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479616: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479617: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479627: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479628: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479628: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479638: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479644: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479644: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479655: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479656: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479656: kvm_entry: vcpu 0 ________________________________

1 0

Re: [SeaBIOS] [PATCH] Support multiple hard disks in boot list.
by Gaurav Poothia 14 Jul '17

14 Jul '17

Hi Kevin, I also tried this patch to fallback from non bootable SCSI disk to bootable SCSI disk with Windows installed. That worked too. So while we cannot see the Windows bootloader source it sure seems to be honoring the DL values other than 0x80 Thanks Gaurav On Mon, Jul 10, 2017 at 1:49 PM, Gaurav Poothia <gaurav.poothia(a)gmail.com> wrote: > Hi Kevin, > Thanks for your response! > > I have tested this successfully against grub (specifically GRUB 2) > Since you asked I went digging for the relevant code in grub - here is > the line of code that will validate range of acceptable DL values and > if acceptable jump ahead to boot from that disk and skip hardcoding DL > to 0x80: > https://github.com/coreos/grub/blob/master/grub-core/boot/i386/pc/boot.S#L2… > > So for example if bios were to set DL to 0x81 (by fallback logic in > the patch) that will be acceptable to grub > > On Fri, Jul 7, 2017 at 7:55 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Fri, Jun 30, 2017 at 08:48:27PM -0400, Gaurav Poothia wrote: >>> If multiple disks in boot order and first is unbootable >>> then fallback to other disks in list. >> [...] >>> @@ -731,7 +736,10 @@ do_boot(int seq_nr) >>> break; >>> case IPL_TYPE_HARDDISK: >>> printf("Booting from Hard Disk...\n"); >>> - boot_disk(0x80, 1); >>> + if (ie->hdid == -1) >>> + boot_disk(0x80 , 1); >>> + else >>> + boot_disk(0x80 + ie->hdid, 1); >>> break; >>> case IPL_TYPE_CDROM: >>> boot_cdrom((void*)ie->vector); >> >> Ultimately, what this patch does is set the DL register to something >> other than 0x80. I tested this approach a few years ago, and at the >> time I could not find a single bootloader that used DL. What >> bootloaders did you test with this, and which ones worked and did not >> work? >> >> -Kevin > > > > -- > Kiva.org - Loans That Change Lives -- Kiva.org - Loans That Change Lives

1 0

Re: [SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and possible pages
by Ivan Ivanov 12 Jul '17

12 Jul '17

Maybe you are correct - it is hard to fill a page (get 18 entries) during the normal usage scenario - when not adding a lot of slightly different versions of payload for debug purposes... However, at least one person except me (Gerd Hoffmann) thought its a nice feature to have, so I decided to spend some time to implement and test it. If all the devices fit at 1 page - there will be no changes at user interface, no paging enabled. This paging enables by itself only when more than 18 entries are detected - only when it is necessary, all the other time this code is inactive If I remember correctly, applying this whole patch (with paging included) increases seabios rom size just by ~250 bytes, removing the paging wouldn't give any noticeable benefit in size. So personally I don't see any downsides and will continue using this patch at its' current version ;) 2017-07-12 2:16 GMT+03:00 Ivan Ivanov <qmastery16(a)gmail.com>: > Maybe you are correct - it is hard to fill a page (get 18 entries) > during the normal usage scenario - when not adding a lot of slightly > different versions of payload for debug purposes... However, at least > one person except me (Gerd Hoffmann) thought its a nice feature to > have, so I decided to spend some time to implement and test it. If all > the devices fit at 1 page - there will be no changes at user > interface, no paging enabled. This paging enables by itself only when > more than 18 entries are detected - only when it is necessary, all the > other time this code is inactive > > If I remember correctly, applying this whole patch (with paging > included) increases seabios rom size just by ~250 bytes, removing the > paging wouldn't give any noticeable benefit in size. So personally I > don't see any downsides and will continue using this patch at its' > current version ;) > > > 2017-07-07 17:51 GMT+03:00 Kevin O'Connor <kevin(a)koconnor.net>: >> On Sun, Jul 02, 2017 at 12:38:00AM +0300, Ivan Ivanov wrote: >>> Recently I discovered another area where this "35 devices" patch is useful. >>> When you need to debug a payload on the real coreboot-supported hardware, >>> to speed up the development you could include a lot of slightly different >>> versions of the same payload to your coreboot ROM, and then >>> could test them all after a single flashing, saving your time and >>> reducing the wearing out of SPI flash >> >> Sorry for the delay in responding. >> >> I think it would be useful to support more than 10 devices in the boot >> menu. I'm not convinced we need a paging menu though. I suspect that >> increasing the count to 20 (or whatever fits on a page) should be >> sufficient for now. >> >> -Kevin

1 0

cbfstool without cloning the whole repository? Use script for <2M download
by Ivan Ivanov 12 Jul '17

12 Jul '17

Dear friends, sometimes you need to do a few operations with coreboot.rom (e.g. update its' payload) without changing coreboot.rom's main code. If you have bad Internet connection or just want to quickly get the latest version of cbfstool without cloning the whole coreboot/vboot repositories - my bash script below will really help you! It downloads only the files required for the successful compilation of cbfstool - whole ./util/cbfstool directory (93 files, ~1,3M size) and all the dependencies: ./src/commonlib - 20 files, ~152K ./src/vendorcode/intel/edk2/uefi_2.4/ - 26 files, 272K ./src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h - ~4K ((( I don't understand what Intel is doing here, but I can't build without these files! ))) ./3rdparty/vboot/firmware/2lib/ - 17 files, 170K ./3rdparty/vboot/firmware/include/vb2_api.h - ~1K In total, its 158 files and just 1.9M - less than 2M ! And it builds OK. Hope it will be useful for you ;-) ### SCRIPT BEGIN ### wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/util/cbfstool/ wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/commonlib/ \ --exclude-directories=/cgit/coreboot.git/plain/src/commonlib/storage/ \ --reject=configstring.c,iobuf.c,cbmem_id.h,configstring.h,coreboot_tables.h,\ fmap_serialized.h,iobuf.h,sd_mmc_ctrlr.h,sdhci.h,stdlib.h,storage.h,\ timestamp_serialized.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/ed… wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/fs… wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off --directory-prefix=./3rdparty/vboot/ \ https://review.coreboot.org/cgit/vboot.git/plain/firmware/2lib/ \ --reject=2api.c,2crc8.c,2hmac.c,2misc.c,2nvstorage.c,2rsa.c,2secdata.c,\ 2secdatak.c,2stub.c,2tpm_bootmode.c,2crc8.h,2hmac.h,2misc.h,\ 2nvstorage_fields.h,2nvstorage.h,2rsa.h,2secdata.h,2tpm_bootmode.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off --directory-prefix=./3rdparty/vboot/ \ https://review.coreboot.org/cgit/vboot.git/plain/firmware/include/vb2_api.h cd ./util/cbfstool/ make all ### SCRIPT END ###

1 0

[PATCH] virtio: IOMMU support
by Jason Wang 12 Jul '17

12 Jul '17

Since we don't enable IOMMU at all, we can then simply enable the IOMMU support by claiming the support of VIRITO_F_IOMMU_PLATFORM. This fixes booting failure when iommu_platform is set from qemu cli. Signed-off-by: Jason Wang <jasowang(a)redhat.com> --- src/hw/virtio-blk.c | 3 ++- src/hw/virtio-ring.h | 1 + src/hw/virtio-scsi.c | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c index dca7855..901b8f5 100644 --- a/src/hw/virtio-blk.c +++ b/src/hw/virtio-blk.c @@ -118,13 +118,14 @@ init_virtio_blk(void *data) struct vp_device *vp = &vdrive->vp; u64 features = vp_get_features(vp); u64 version1 = 1ull << VIRTIO_F_VERSION_1; + u64 iommu_platform = 1ull << VIRTIO_F_IOMMU_PLATFORM; u64 blk_size = 1ull << VIRTIO_BLK_F_BLK_SIZE; if (!(features & version1)) { dprintf(1, "modern device without virtio_1 feature bit: %pP\n", pci); goto fail; } - features = features & (version1 | blk_size); + features = features & (version1 | iommu_platform | blk_size); vp_set_features(vp, features); status |= VIRTIO_CONFIG_S_FEATURES_OK; vp_set_status(vp, status); diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h index 7665fd5..8604a01 100644 --- a/src/hw/virtio-ring.h +++ b/src/hw/virtio-ring.h @@ -18,6 +18,7 @@ /* v1.0 compliant. */ #define VIRTIO_F_VERSION_1 32 +#define VIRTIO_F_IOMMU_PLATFORM 33 #define MAX_QUEUE_NUM (128) diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c index 7490ec0..4eea5c3 100644 --- a/src/hw/virtio-scsi.c +++ b/src/hw/virtio-scsi.c @@ -163,12 +163,13 @@ init_virtio_scsi(void *data) if (vp->use_modern) { u64 features = vp_get_features(vp); u64 version1 = 1ull << VIRTIO_F_VERSION_1; + u64 iommu_platform = 1ull << VIRTIO_F_IOMMU_PLATFORM; if (!(features & version1)) { dprintf(1, "modern device without virtio_1 feature bit: %pP\n", pci); goto fail; } - vp_set_features(vp, version1); + vp_set_features(vp, features & (version1 | iommu_platform)); status |= VIRTIO_CONFIG_S_FEATURES_OK; vp_set_status(vp, status); if (!(vp_get_status(vp) & VIRTIO_CONFIG_S_FEATURES_OK)) { -- 2.7.4

3 2

[PATCH] Support multiple hard disks in boot list.
by Gaurav Poothia 11 Jul '17

11 Jul '17

If multiple disks in boot order and first is unbootable then fallback to other disks in list. Signed-off-by: Gaurav Poothia <gaurav.poothia(a)gmail.com> --- src/block.c | 3 ++- src/block.h | 2 +- src/boot.c | 30 +++++++++++++++++++----------- 3 files changed, 22 insertions(+), 13 deletions(-) diff --git a/src/block.c b/src/block.c index d104f6d..5c78533 100644 --- a/src/block.c +++ b/src/block.c @@ -238,7 +238,7 @@ add_drive(struct drive_s **idmap, u8 *count, struct drive_s *drive) } // Map a hard drive -void +int map_hd_drive(struct drive_s *drive) { ASSERT32FLAT(); @@ -252,6 +252,7 @@ map_hd_drive(struct drive_s *drive) // Fill "fdpt" structure. fill_fdpt(drive, hdid); + return hdid; } // Map a cd diff --git a/src/block.h b/src/block.h index f03ec38..68f2f32 100644 --- a/src/block.h +++ b/src/block.h @@ -109,7 +109,7 @@ extern u8 *bounce_buf_fl; struct drive_s *getDrive(u8 exttype, u8 extdriveoffset); int getDriveId(u8 exttype, struct drive_s *drive); void map_floppy_drive(struct drive_s *drive); -void map_hd_drive(struct drive_s *drive); +int map_hd_drive(struct drive_s *drive); void map_cd_drive(struct drive_s *drive); struct int13dpt_s; int fill_edd(struct segoff_s edd, struct drive_s *drive_gf); diff --git a/src/boot.c b/src/boot.c index 59623fb..9b9cf91 100644 --- a/src/boot.c +++ b/src/boot.c @@ -527,16 +527,16 @@ interactive_bootmenu(void) struct bev_s { int type; u32 vector; + // Applicable to hard disks only + int hdid; }; static struct bev_s BEV[20]; static int BEVCount; static int HaveHDBoot, HaveFDBoot; static void -add_bev(int type, u32 vector) +add_bev(int type, u32 vector, int hdid) { - if (type == IPL_TYPE_HARDDISK && HaveHDBoot++) - return; if (type == IPL_TYPE_FLOPPY && HaveFDBoot++) return; if (BEVCount >= ARRAY_SIZE(BEV)) @@ -544,12 +544,15 @@ add_bev(int type, u32 vector) struct bev_s *bev = &BEV[BEVCount++]; bev->type = type; bev->vector = vector; + bev->hdid = hdid; } + // Prepare for boot - show menu and run bcvs. void bcv_prepboot(void) { + int hdid = -1; if (! CONFIG_BOOT) return; @@ -563,28 +566,30 @@ bcv_prepboot(void) switch (pos->type) { case IPL_TYPE_BCV: call_bcv(pos->vector.seg, pos->vector.offset); - add_bev(IPL_TYPE_HARDDISK, 0); + add_bev(IPL_TYPE_HARDDISK, 0, -1); break; case IPL_TYPE_FLOPPY: map_floppy_drive(pos->drive); - add_bev(IPL_TYPE_FLOPPY, 0); + add_bev(IPL_TYPE_FLOPPY, 0, -1); break; case IPL_TYPE_HARDDISK: - map_hd_drive(pos->drive); - add_bev(IPL_TYPE_HARDDISK, 0); + hdid = map_hd_drive(pos->drive); + add_bev(IPL_TYPE_HARDDISK, 0, hdid); + HaveHDBoot++; break; case IPL_TYPE_CDROM: map_cd_drive(pos->drive); // NO BREAK default: - add_bev(pos->type, pos->data); + add_bev(pos->type, pos->data, -1); break; } } // If nothing added a floppy/hd boot - add it manually. - add_bev(IPL_TYPE_FLOPPY, 0); - add_bev(IPL_TYPE_HARDDISK, 0); + add_bev(IPL_TYPE_FLOPPY, 0, -1); + if (HaveHDBoot == 0) + add_bev(IPL_TYPE_HARDDISK, 0, -1); } @@ -731,7 +736,10 @@ do_boot(int seq_nr) break; case IPL_TYPE_HARDDISK: printf("Booting from Hard Disk...\n"); - boot_disk(0x80, 1); + if (ie->hdid == -1) + boot_disk(0x80 , 1); + else + boot_disk(0x80 + ie->hdid, 1); break; case IPL_TYPE_CDROM: boot_cdrom((void*)ie->vector); -- 1.8.3.1

2 2

Re: [SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and possible pages
by Kevin O'Connor 08 Jul '17

08 Jul '17

On Sun, Jul 02, 2017 at 12:38:00AM +0300, Ivan Ivanov wrote: > Recently I discovered another area where this "35 devices" patch is useful. > When you need to debug a payload on the real coreboot-supported hardware, > to speed up the development you could include a lot of slightly different > versions of the same payload to your coreboot ROM, and then > could test them all after a single flashing, saving your time and > reducing the wearing out of SPI flash Sorry for the delay in responding. I think it would be useful to support more than 10 devices in the boot menu. I'm not convinced we need a paging menu though. I suspect that increasing the count to 20 (or whatever fits on a page) should be sufficient for now. -Kevin

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS