SeaBIOS

seabios@seabios.org

3783 discussions

[PATCH 1/2] virtio: Use threads when scanning for virtio devices
by Kevin O'Connor 19 Apr '16

19 Apr '16

Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/hw/virtio-blk.c | 6 ++++-- src/hw/virtio-scsi.c | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c index 2dfd0c3..dca7855 100644 --- a/src/hw/virtio-blk.c +++ b/src/hw/virtio-blk.c @@ -15,6 +15,7 @@ #include "pcidevice.h" // foreachpci #include "pci_ids.h" // PCI_DEVICE_ID_VIRTIO_BLK #include "pci_regs.h" // PCI_VENDOR_ID +#include "stacks.h" // run_thread #include "std/disk.h" // DISK_RET_SUCCESS #include "string.h" // memset #include "util.h" // usleep @@ -93,8 +94,9 @@ virtio_blk_process_op(struct disk_op_s *op) } static void -init_virtio_blk(struct pci_device *pci) +init_virtio_blk(void *data) { + struct pci_device *pci = data; u8 status = VIRTIO_CONFIG_S_ACKNOWLEDGE | VIRTIO_CONFIG_S_DRIVER; dprintf(1, "found virtio-blk at %pP\n", pci); struct virtiodrive_s *vdrive = malloc_fseg(sizeof(*vdrive)); @@ -203,6 +205,6 @@ virtio_blk_setup(void) (pci->device != PCI_DEVICE_ID_VIRTIO_BLK_09 && pci->device != PCI_DEVICE_ID_VIRTIO_BLK_10)) continue; - init_virtio_blk(pci); + run_thread(init_virtio_blk, pci); } } diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c index 322d469..5fb9409 100644 --- a/src/hw/virtio-scsi.c +++ b/src/hw/virtio-scsi.c @@ -16,6 +16,7 @@ #include "pcidevice.h" // foreachpci #include "pci_ids.h" // PCI_DEVICE_ID_VIRTIO_BLK #include "pci_regs.h" // PCI_VENDOR_ID +#include "stacks.h" // run_thread #include "std/disk.h" // DISK_RET_SUCCESS #include "string.h" // memset #include "util.h" // usleep @@ -132,8 +133,9 @@ virtio_scsi_scan_target(struct pci_device *pci, struct vp_device *vp, } static void -init_virtio_scsi(struct pci_device *pci) +init_virtio_scsi(void *data) { + struct pci_device *pci = data; dprintf(1, "found virtio-scsi at %pP\n", pci); struct vring_virtqueue *vq = NULL; struct vp_device *vp = malloc_high(sizeof(*vp)); @@ -199,6 +201,6 @@ virtio_scsi_setup(void) (pci->device != PCI_DEVICE_ID_VIRTIO_SCSI_09 && pci->device != PCI_DEVICE_ID_VIRTIO_SCSI_10)) continue; - init_virtio_scsi(pci); + run_thread(init_virtio_scsi, pci); } } -- 2.5.5

1 2

[PATCH 1/2] optionroms: Drop support for CONFIG_OPTIONROMS_DEPLOYED
by Kevin O'Connor 19 Apr '16

19 Apr '16

No modern software uses this option and it complicates the code. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/Kconfig | 8 -------- src/fw/shadow.c | 15 +------------- src/optionroms.c | 61 ++++++++++++++++++++------------------------------------ 3 files changed, 23 insertions(+), 61 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index de39b38..e767be1 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -395,14 +395,6 @@ menu "BIOS interfaces" default y help Support finding and running option roms during POST. - config OPTIONROMS_DEPLOYED - depends on OPTIONROMS && QEMU - bool "Option roms are already at 0xc0000-0xf0000" - default n - help - Select this if option ROMs are already copied to - 0xc0000-0xf0000. This must only be selected when using - Bochs or QEMU versions older than 0.12. config PMM depends on OPTIONROMS bool "PMM interface" diff --git a/src/fw/shadow.c b/src/fw/shadow.c index bdb5c5b..f766bb5 100644 --- a/src/fw/shadow.c +++ b/src/fw/shadow.c @@ -26,24 +26,11 @@ static void __make_bios_writable_intel(u16 bdf, u32 pam0) { // Make ram from 0xc0000-0xf0000 writable - int clear = 0; int i; for (i=0; i<6; i++) { u32 pam = pam0 + 1 + i; - int reg = pci_config_readb(bdf, pam); - if (CONFIG_OPTIONROMS_DEPLOYED && (reg & 0x11) != 0x11) { - // Need to copy optionroms to work around qemu implementation - void *mem = (void*)(BUILD_ROM_START + i * 32*1024); - memcpy((void*)BUILD_BIOS_TMP_ADDR, mem, 32*1024); - pci_config_writeb(bdf, pam, 0x33); - memcpy(mem, (void*)BUILD_BIOS_TMP_ADDR, 32*1024); - clear = 1; - } else { - pci_config_writeb(bdf, pam, 0x33); - } + pci_config_writeb(bdf, pam, 0x33); } - if (clear) - memset((void*)BUILD_BIOS_TMP_ADDR, 0, 32*1024); // Make ram from 0xf0000-0x100000 writable int reg = pci_config_readb(bdf, pam0); diff --git a/src/optionroms.c b/src/optionroms.c index 9897753..65f7fe0 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -347,28 +347,16 @@ optionrom_setup(void) memset(sources, 0, sizeof(sources)); u32 post_vga = rom_get_last(); - if (CONFIG_OPTIONROMS_DEPLOYED) { - // Option roms are already deployed on the system. - u32 pos = post_vga; - while (pos < rom_get_max()) { - int ret = init_optionrom((void*)pos, 0, 0); - if (ret) - pos += OPTION_ROM_ALIGN; - else - pos = rom_get_last(); - } - } else { - // Find and deploy PCI roms. - struct pci_device *pci; - foreachpci(pci) { - if (pci->class == PCI_CLASS_DISPLAY_VGA || pci->have_driver) - continue; - init_pcirom(pci, 0, sources); - } - - // Find and deploy CBFS roms not associated with a device. - run_file_roms("genroms/", 0, sources); + // Find and deploy PCI roms. + struct pci_device *pci; + foreachpci(pci) { + if (pci->class == PCI_CLASS_DISPLAY_VGA || pci->have_driver) + continue; + init_pcirom(pci, 0, sources); } + + // Find and deploy CBFS roms not associated with a device. + run_file_roms("genroms/", 0, sources); rom_reserve(0); // All option roms found and deployed - now build BEV/BCV vectors. @@ -427,26 +415,21 @@ vgarom_setup(void) RunPCIroms = romfile_loadint("etc/pci-optionrom-exec", 2); ScreenAndDebug = romfile_loadint("etc/screen-and-debug", 1); - if (CONFIG_OPTIONROMS_DEPLOYED) { - // Option roms are already deployed on the system. - init_optionrom((void*)BUILD_ROM_START, 0, 1); - } else { - // Clear option rom memory - memset((void*)BUILD_ROM_START, 0, rom_get_max() - BUILD_ROM_START); - - // Find and deploy PCI VGA rom. - struct pci_device *pci; - foreachpci(pci) { - if (!is_pci_vga(pci)) - continue; - vgahook_setup(pci); - init_pcirom(pci, 1, NULL); - break; - } + // Clear option rom memory + memset((void*)BUILD_ROM_START, 0, rom_get_max() - BUILD_ROM_START); - // Find and deploy CBFS vga-style roms not associated with a device. - run_file_roms("vgaroms/", 1, NULL); + // Find and deploy PCI VGA rom. + struct pci_device *pci; + foreachpci(pci) { + if (!is_pci_vga(pci)) + continue; + vgahook_setup(pci); + init_pcirom(pci, 1, NULL); + break; } + + // Find and deploy CBFS vga-style roms not associated with a device. + run_file_roms("vgaroms/", 1, NULL); rom_reserve(0); if (rom_get_last() == BUILD_ROM_START) -- 2.5.5

1 2

[PATCH 1/2] block: Move send_disk_op() from block.c to disk.c
by Kevin O'Connor 19 Apr '16

19 Apr '16

The send_disk_op() function is only called from the 16bit handlers found in disk.c. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/block.c | 34 +--------------------------------- src/block.h | 1 - src/disk.c | 32 ++++++++++++++++++++++++++++++++ 3 files changed, 33 insertions(+), 34 deletions(-) diff --git a/src/block.c b/src/block.c index d9de29f..a383574 100644 --- a/src/block.c +++ b/src/block.c @@ -22,7 +22,7 @@ #include "hw/virtio-scsi.h" // virtio_scsi_process_op #include "malloc.h" // malloc_low #include "output.h" // dprintf -#include "stacks.h" // stack_hop +#include "stacks.h" // call32 #include "std/disk.h" // struct dpte_s #include "string.h" // checksum #include "util.h" // process_floppy_op @@ -613,35 +613,3 @@ process_op(struct disk_op_s *op) op->count = 0; return ret; } - -// Execute a "disk_op_s" request - this runs on the extra stack. -static int -__send_disk_op(struct disk_op_s *op_far, u16 op_seg) -{ - struct disk_op_s dop; - memcpy_far(GET_SEG(SS), &dop - , op_seg, op_far - , sizeof(dop)); - - dprintf(DEBUG_HDL_13, "disk_op d=%p lba=%d buf=%p count=%d cmd=%d\n" - , dop.drive_gf, (u32)dop.lba, dop.buf_fl - , dop.count, dop.command); - - int status = process_op(&dop); - - // Update count with total sectors transferred. - SET_FARVAR(op_seg, op_far->count, dop.count); - - return status; -} - -// Execute a "disk_op_s" request by jumping to the extra 16bit stack. -int -send_disk_op(struct disk_op_s *op) -{ - ASSERT16(); - if (! CONFIG_DRIVES) - return -1; - - return stack_hop(__send_disk_op, op, GET_SEG(SS)); -} diff --git a/src/block.h b/src/block.h index a5f38c4..0f15ff9 100644 --- a/src/block.h +++ b/src/block.h @@ -115,7 +115,6 @@ int fill_edd(struct segoff_s edd, struct drive_s *drive_gf); void block_setup(void); int default_process_op(struct disk_op_s *op); int process_op(struct disk_op_s *op); -int send_disk_op(struct disk_op_s *op); int create_bounce_buf(void); #endif // block.h diff --git a/src/disk.c b/src/disk.c index 3854d00..bcd6a09 100644 --- a/src/disk.c +++ b/src/disk.c @@ -87,6 +87,38 @@ getLCHS(struct drive_s *drive_gf) return res; } +// Execute a "disk_op_s" request - this runs on the extra stack. +static int +__send_disk_op(struct disk_op_s *op_far, u16 op_seg) +{ + struct disk_op_s dop; + memcpy_far(GET_SEG(SS), &dop + , op_seg, op_far + , sizeof(dop)); + + dprintf(DEBUG_HDL_13, "disk_op d=%p lba=%d buf=%p count=%d cmd=%d\n" + , dop.drive_gf, (u32)dop.lba, dop.buf_fl + , dop.count, dop.command); + + int status = process_op(&dop); + + // Update count with total sectors transferred. + SET_FARVAR(op_seg, op_far->count, dop.count); + + return status; +} + +// Execute a "disk_op_s" request by jumping to the extra 16bit stack. +static int +send_disk_op(struct disk_op_s *op) +{ + ASSERT16(); + if (! CONFIG_DRIVES) + return -1; + + return stack_hop(__send_disk_op, op, GET_SEG(SS)); +} + // Perform read/write/verify using old-style chs accesses static void noinline basic_access(struct bregs *regs, struct drive_s *drive_gf, u16 command) -- 2.5.5

1 2

Add support for legacy USB keyboard/mouse (PS/2 emulation for USB?)
by Adam Rutkowski 18 Apr '16

18 Apr '16

Hello, I think this is the right place to write about this. From a few days I'm fighting with not USB-aware OS-es in QEMU (like Windows 98, IBM OS/2, MS-DOS etc.). When I assign real USB keyboard and mouse to VM, keyboard partially works in DOS (keys like Alt aren't working), but mouse doesn't work at all. After starting, let's say Windows 98 Setup, keyboard stops working too. From my experience these peripherals works only in newer OSes like Windows 2000+ or Linux, because they initialize their own USB HID driver. I'm not using QEMU's emulated USB HID devices, because I utilize VGA passthrough, so I need direct access from guest machine. Summarizing: is it possible to add full support for USB keyboard and mouse in SeaBIOS? P.S. I apologize for any grammatical errors.

3 3

[RFC] Document and rework debug levels
by Kevin O'Connor 08 Apr '16

08 Apr '16

There are a number of debug levels in the SeaBIOS code today. Unfortunately, much of the code does not follow any particular standard for which debug level to use. This is becoming cumbersome for a few reasons: - some people want fewer debug messages to reduce boot time, but still want critical messages (eg, error messages). Debug level 1 can be too verbose while debug level 0 disables all messages. - some drivers become very verbose before other drivers, and thus depending on a user's hardware, the user might get flooded with messages they don't want before seeing the important messages from the driver they were looking for - when writing a new driver, it's not easy for a developer to know what debug level to choose I'm proposing that the debug levels be documented and that all of the debug messages in SeaBIOS be reworked to follow that documentation. Here are the debug levels I propose using: Level 1: - SeaBIOS version banner - Major error messages and major warning messages that are likely indicative of an error - Screen output (ie, printf) would also be available at this level when screen-and-debug is true Level 2: - Critical memory layout information. This would include the e820 map prior to booting and similar information about UMB memory, EBDA memory, BIOS table locations, etc. Level 3: - Found hardware for which there is a SeaBIOS driver and critical information about that hardware (such as its address, hardware version, hardware capabilities, etc.) Level 4: - Major code flow events between SeaBIOS phases (eg, post, boot, resume phases) Level 5: - Code flow notifications at driver and subsystem startup (eg, "init usb\n" type messages) - Thread startup and shutdown messages Level 6: - Basic driver and subsystem debugging. This would be driver specific messages that are not expected to be called with high frequency (ie, not called on every disk access nor on every keyboard access, etc.) Finally, for debug messages that could be called with high frequency (eg, on each disk read), I propose defining a DEBUG_xyz at the top of the particular driver source code file which would default to 9 and a developer could change to a lower number when working on that code. So, for example, DEBUG_xhci could be introduced and be used on dprintf() messages that are invoked on each xhci transfer. As part of this proposal, the default debug level would change from level 1 to level 4. Most dprintf level 1 calls in the code would change to a level between 1 and 4. Most driver dprintf calls between levels 3-8 would end up changing to level 6. Most dprintf calls with 9 (or higher) would instead get a DEBUG_xyz definition. Thoughts? -Kevin

3 5

Re: [SeaBIOS] virtio-blk ... block size 4096 is unsupported
by Kevin Wolf 06 Apr '16

06 Apr '16

Am 05.04.2016 um 20:24 hat James Shimer geschrieben: > Thanks for the responses. What you've both said makes total sense. > We've tried 512 logical/ 4k physical and it works fine with Seabios. > Thanks Laszlo for the OVMF tip, that's totally the route we need to > take. In practice, I don't think there is a big difference for disk accesses between using 4k logical (with OVMF) and using 512b logical (with either SeaBIOS or OVMF). So if you just want to access your data optimally in the guest and don't care if it really looks like 4kn there, using a 512e setup with SeaBIOS is probably completely fine. It is very likely that your OS is already using 4k aligned requests because it knows the physical sector size, and apart from that both the file system block size and the page size aren't smaller than 4k either. So while the emulation of 512b sectors costs some performance (it is done by qemu in this configuration), it should really only kick in for the boot loader and everything else should be using correctly aligned requests without any need for emulation. Kevin > ________________________________________ > From: Laszlo Ersek <lersek(a)redhat.com> > Sent: Tuesday, April 5, 2016 12:49 PM > To: Kevin O'Connor > Cc: James Shimer; Kevin Wolf; seabios(a)seabios.org > Subject: Re: [SeaBIOS] virtio-blk ... block size 4096 is unsupported > > On 04/05/16 18:36, Kevin O'Connor wrote: > > On Tue, Apr 05, 2016 at 02:31:53PM +0200, Laszlo Ersek wrote: > >> On 04/05/16 06:25, James Shimer wrote: > >>> I've been doing some testing if KVM with 4K physical sector virtio > >>> disks and they work with KVM as a none boot disk. We'd like to be > >>> able to boot a 4k physical sector disk in KVM, is there 4K support in > >>> any seabios newer/upcoming releases, or is there a way to configure > >>> for 4k sectors? > >>> > >>> reference from master > >>> src/hw/virtio-blk.c lin 142 > >>> > >>> if (vdrive->drive.blksize != DISK_SECTOR_SIZE) { > >>> dprintf(1, "virtio-blk %pP block size %d is unsupported\n", > >>> pci, vdrive->drive.blksize); > >>> goto fail; > >>> } > >> > >> This code dates back to 4030db0d2c5a7. > >> > >> I'm not an expert, but I think BIOS interfaces don't support a sector > >> size different from 512 B. It seems that a drive with 4096 B physical > >> sectors should enable (the emulation of) a 512 B logical sector size, so > >> that it can work with code that assumes an 512 B sector size. > >> > >> https://en.wikipedia.org/wiki/Advanced_Format#512e > > > > The EDD standard ( https://en.wikipedia.org/wiki/Enhanced_Disk_Drive ) > > allows for 4K blocks. However, the older BIOS interface (eg, int > > 1301) only support 512 byte sectors. This means that the BIOS would > > need to emulate 512 byte reads should one of the older interfaces be > > called on one of these drives. This isn't difficult as SeaBIOS > > already does this for cdroms. > > That sounds great, thanks. I should have thought of CD-ROMs, I guess. > > > > >> I guess for a virtio-blk disk, that means: > >> > >> -device virtio-blk-pci,physical_block_size=4096,logical_block_size=512 > > > > In practice, almost all real drives seem to do the above. So, adding > > support for drives that don't has not previously been a priority. > > Right, I missed that 512e could be implemented in SeaBIOS itself (and I > completely missed that it had been, for CD-ROMs). > > Thanks! > Laszlo

1 0

Re: [SeaBIOS] virtio-blk ... block size 4096 is unsupported
by Laszlo Ersek 06 Apr '16

06 Apr '16

On 04/05/16 06:25, James Shimer wrote: > > Hi, > > I've been doing some testing if KVM with 4K physical sector virtio > disks and they work with KVM as a none boot disk. We'd like to be > able to boot a 4k physical sector disk in KVM, is there 4K support in > any seabios newer/upcoming releases, or is there a way to configure > for 4k sectors? > > reference from master > src/hw/virtio-blk.c lin 142 > > if (vdrive->drive.blksize != DISK_SECTOR_SIZE) { > dprintf(1, "virtio-blk %pP block size %d is unsupported\n", > pci, vdrive->drive.blksize); > goto fail; > } This code dates back to 4030db0d2c5a7. I'm not an expert, but I think BIOS interfaces don't support a sector size different from 512 B. It seems that a drive with 4096 B physical sectors should enable (the emulation of) a 512 B logical sector size, so that it can work with code that assumes an 512 B sector size. https://en.wikipedia.org/wiki/Advanced_Format#512e I guess for a virtio-blk disk, that means: -device virtio-blk-pci,physical_block_size=4096,logical_block_size=512 If your virtio disk is "4K native": https://en.wikipedia.org/wiki/Advanced_Format#4K_native (which I think corresponds to the following QEMU command line option (based on advice I had received earlier from Kevin Wolf): -device virtio-blk-pci,physical_block_size=4096,\ logical_block_size=4096,\ min_io_size=4096 ) then I believe BIOS interfaces / booting might not support the disk, by design, at all. And for that reason, I'll make an exception, and "peddle" OVMF (sorry -- I feel bad about doing this on the SeaBIOS list). UEFI (and GPT) support "4K native" by design, and OVMF supports it for virtio-blk devices. (OVMF also supports 512e.) I suggest that you repeat your test with a guest OS that you install afresh on top of OVMF. You can find pre-built OVMF binaries (RPMs) at <https://www.kraxel.org/repos/>. I recommend using them with libvirt: <https://fedoraproject.org/wiki/Using_UEFI_with_QEMU#Install_a_Fedora_VM_wit…>. If you have questions about OVMF, please let's continue on edk2-devel, to keep the noise down on the SeaBIOS list. (Note: you will have to subscribe to edk2-devel first, before you can post. Please see <https://lists.01.org/mailman/listinfo/edk2-devel>.) Thanks Laszlo

3 3

Re: [SeaBIOS] virtio-blk ... block size 4096 is unsupported
by James Shimer 05 Apr '16

05 Apr '16

After thinking about this some more, I'm not sure there is anything that can be done due to the fact that boot is using interfaces that assume 512 byte sectors such as a read sectors 13h. Is that why BIOS/boot is stuck, changing the read to allow 4k sector size could cause buffer over run because the 13h interface doesn't specify the sector size? ________________________________________ From: SeaBIOS <seabios-bounces(a)seabios.org> on behalf of James Shimer <JamesShimer(a)msn.com> Sent: Tuesday, April 5, 2016 12:25 AM To: seabios(a)seabios.org Subject: [SeaBIOS] virtio-blk ... block size 4096 is unsupported Hi, I've been doing some testing if KVM with 4K physical sector virtio disks and they work with KVM as a none boot disk. We'd like to be able to boot a 4k physical sector disk in KVM, is there 4K support in any seabios newer/upcoming releases, or is there a way to configure for 4k sectors? reference from master src/hw/virtio-blk.c lin 142 if (vdrive->drive.blksize != DISK_SECTOR_SIZE) { dprintf(1, "virtio-blk %pP block size %d is unsupported\n", pci, vdrive->drive.blksize); goto fail; } Thanks, Jim _______________________________________________ SeaBIOS mailing list SeaBIOS(a)seabios.org https://www.coreboot.org/mailman/listinfo/seabios

1 0

virtio-blk ... block size 4096 is unsupported
by James Shimer 05 Apr '16

05 Apr '16

Hi, I've been doing some testing if KVM with 4K physical sector virtio disks and they work with KVM as a none boot disk. We'd like to be able to boot a 4k physical sector disk in KVM, is there 4K support in any seabios newer/upcoming releases, or is there a way to configure for 4k sectors? reference from master src/hw/virtio-blk.c lin 142 if (vdrive->drive.blksize != DISK_SECTOR_SIZE) { dprintf(1, "virtio-blk %pP block size %d is unsupported\n", pci, vdrive->drive.blksize); goto fail; } Thanks, Jim

1 0

Re: [SeaBIOS] Build failed in Jenkins: seabios #220
by Kevin O'Connor 01 Apr '16

01 Apr '16

On Wed, Mar 30, 2016 at 07:50:33PM +0200, Jenkins Build Host wrote: > See <http://jenkins.xeni.kraxel.org:8080/job/seabios/220/changes> > > Changes: > > [kevin] Support for booting from LSI Logic LSI53C1030, SAS1068, SAS1068e [...] > Compile checking out/src/hw/mpt-scsi.o > src/hw/mpt-scsi.c: In function 'init_mpt_scsi': > src/hw/mpt-scsi.c:281:5: error: 'for' loop initial declarations are only allowed in C99 mode > for (int i = 0; i < 7; i++) > ^ > src/hw/mpt-scsi.c:281:5: note: use option -std=c99 or -std=gnu99 to compile your code > make: *** [out/src/hw/mpt-scsi.o] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.YLsXMX (%build) It's interesting that newer compilers accept the 'int i' declaration inside of for loops - I didn't realize that was allowed in C99. In any case, I pulled the declaration outside the loop to suppress the error, and I committed the change. -Kevin

4 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS