[SeaBIOS] [PATCH v3] add virtio-scsi driver
virtio-scsi is a simple HBA that talks to the host via a single
vring. The implementation looks like a hybrid of usb-msc and
virtio-blk.
Reviewed-by: Laszlo Ersek
Signed-off-by: Paolo Bonzini
---
On top of your patch "Register drives directly in scsi_init_drive()".
Makefile |2 +-
src/Kconfig |6 ++
src/block.c |3 +-
src/blockcmd.c|5 +-
src/boot.c| 14
src/boot.h|1 +
src/disk.c|3 +-
src/disk.h|1 +
src/pci_ids.h |1 +
src/post.c|2 +
src/virtio-scsi.c | 177 +
src/virtio-scsi.h | 47 ++
12 files changed, 258 insertions(+), 4 deletions(-)
create mode 100644 src/virtio-scsi.c
create mode 100644 src/virtio-scsi.h
diff --git a/Makefile b/Makefile
index 3b56225..5c2083a 100644
--- a/Makefile
+++ b/Makefile
@@ -15,7 +15,7 @@ SRCBOTH=misc.c stacks.c pmm.c output.c util.c block.c
floppy.c ata.c mouse.c \
kbd.c pci.c serial.c clock.c pic.c cdrom.c ps2port.c smp.c resume.c \
pnpbios.c pirtable.c vgahooks.c ramdisk.c pcibios.c blockcmd.c \
usb.c usb-uhci.c usb-ohci.c usb-ehci.c usb-hid.c usb-msc.c \
-virtio-ring.c virtio-pci.c virtio-blk.c apm.c ahci.c
+virtio-ring.c virtio-pci.c virtio-blk.c virtio-scsi.c apm.c ahci.c
SRC16=$(SRCBOTH) system.c disk.c font.c
SRC32FLAT=$(SRCBOTH) post.c shadow.c memmap.c coreboot.c boot.c \
acpi.c smm.c mptable.c smbios.c pciinit.c optionroms.c mtrr.c \
diff --git a/src/Kconfig b/src/Kconfig
index 250663a..53fda9b 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -113,6 +113,12 @@ menu "Hardware support"
default y
help
Support boot from virtio-blk storage.
+config VIRTIO_SCSI
+depends on DRIVES && !COREBOOT
+bool "virtio-scsi controllers"
+default y
+help
+Support boot from virtio-scsi storage.
config FLOPPY
depends on DRIVES
bool "Floppy controller"
diff --git a/src/block.c b/src/block.c
index ccf4ee6..e270cf5 100644
--- a/src/block.c
+++ b/src/block.c
@@ -279,7 +279,7 @@ map_floppy_drive(struct drive_s *drive_g)
static int
process_scsi_op(struct disk_op_s *op)
{
-if (!CONFIG_USB_MSC)
+if (!CONFIG_VIRTIO_SCSI && !CONFIG_USB_MSC)
return 0;
switch (op->command) {
case CMD_READ:
@@ -320,6 +320,7 @@ process_op(struct disk_op_s *op)
case DTYPE_AHCI:
return process_ahci_op(op);
case DTYPE_USB:
+case DTYPE_VIRTIO_SCSI:
return process_scsi_op(op);
default:
op->count = 0;
diff --git a/src/blockcmd.c b/src/blockcmd.c
index dd35501..2769573 100644
--- a/src/blockcmd.c
+++ b/src/blockcmd.c
@@ -12,6 +12,7 @@
#include "ata.h" // atapi_cmd_data
#include "ahci.h" // atapi_cmd_data
#include "usb-msc.h" // usb_cmd_data
+#include "virtio-scsi.h" // virtio_scsi_cmd_data
// Route command to low-level handler.
static int
@@ -25,6 +26,8 @@ cdb_cmd_data(struct disk_op_s *op, void *cdbcmd, u16
blocksize)
return usb_cmd_data(op, cdbcmd, blocksize);
case DTYPE_AHCI:
return ahci_cmd_data(op, cdbcmd, blocksize);
+case DTYPE_VIRTIO_SCSI:
+return virtio_scsi_cmd_data(op, cdbcmd, blocksize);
default:
op->count = 0;
return DISK_RET_EPARAM;
@@ -79,7 +82,7 @@ scsi_is_ready(struct disk_op_s *op)
int
scsi_init_drive(struct drive_s *drive, const char *s, int prio)
{
-if (!CONFIG_USB_MSC)
+if (!CONFIG_USB_MSC && !CONFIG_VIRTIO_SCSI)
return 0;
struct disk_op_s dop;
diff --git a/src/boot.c b/src/boot.c
index e26dad1..c737ba4 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -128,6 +128,20 @@ int bootprio_find_pci_device(struct pci_device *pci)
return find_prio(desc);
}
+int bootprio_find_scsi_device(struct pci_device *pci, int target, int lun)
+{
+if (!CONFIG_BOOTORDER)
+return -1;
+if (!pci)
+// support only pci machine for now
+return -1;
+// Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0
+char desc[256], *p;
+p = build_pci_path(desc, sizeof(desc), "*", pci);
+snprintf(p, desc+sizeof(desc)-p, "/*@0/*@%d,%d", target, lun);
+return find_prio(desc);
+}
+
int bootprio_find_ata_device(struct pci_device *pci, int chanid, int slave)
{
if (!CONFIG_BOOTORDER)
diff --git a/src/boot.h b/src/boot.h
index d776aa1..686f04d 100644
--- a/src/boot.h
+++ b/src/boot.h
@@ -14,6 +14,7 @@ void boot_add_cbfs(void *data, const char *desc, int prio);
void boot_prep(void);
struct pci_device;
int bootprio_find_pci_device(struct pci_device *pci);
+int bootprio_find_scsi_device(struct pci_device *pci, int target, int lun);
int bootprio_find_ata_device(struct pci_device *pci, int chanid, int slave);
int bootprio_find_fdc_device(struct pci_device *pci, int port, int fdid);
int bootprio_find_pci_rom(struct pci_device *pci, int instance);
diff --git a/src/disk.c b/src/disk.c
index
Re: [SeaBIOS] Boot failure with MS-Dos 6.22 (due to bad BIOS build?)
Jan Kiszka wrote: > Well, the Linux kernel can also be built with practically any distro > out there. Yeah. Maybe that gets tested more than building coreboot and SeaBIOS, and so problems are discovered by those who introduce them. > Having a need for a separate toolchain for building x86 on x86 is > a bit overkill IMHO, at least for someone hacking on Seabios only > infrequently like /me. OTOH it takes about 20 minutes to build a toolchain on a reasonably fast machine, and the script makes it quite effortless. > PS: Please avoid "mail-followup-to" in your replies, it messes up To/CC. Moved this discussion to private email. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Boot failure with MS-Dos 6.22 (due to bad BIOS build?)
On 2012-02-27 17:00, Peter Stuge wrote: > Jan Kiszka wrote: >>> Then I noticed, that if I rebuild the BIOS, from the exact same revision >>> 1.6.3.1 revision that is committed in 'seabios' submodule in QEMU, then >>> it works fine. So AFAICT, it is not the Seabios source code at fault, >>> but rather the binary build we have commited to GIT. Should/can we rebuild >>> the bios.bin in GIT ? >> >> Probably not without understanding what causes this strange >> inconsistency. If Seabios builds without errors and then later on fails, >> this is also a bug. >> >> Kevin, what information do you need to assess my tool chain? > > In the coreboot project we have more than 10 years of experience from > distribution toolchains consistently being too broken to build a > working coreboot image. The same problems apply to SeaBIOS. > > As you know, distribution toolchains are heavily patched, presumably > to add some value to the distribution. The patches work fine when the > toolchains should output userland binaries or the odd kernel. They > fail frequently and in countless ways when used to produce bare metal > binaries. > > Within coreboot it is much less effort to build an i386-elf cross > toolchain than to mess with the hundreds if not thousands of issues > in the distribution toolchains. The same applies to SeaBIOS of > course. The script we use in coreboot is here: > > http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/crossgcc > > If you want to investigate and spend time on motivating distributions > to unbreak their toolchains that's awesome, but be prepared to spend > many weeks disassembling binaries and reverse engineering the toolchain. Well, the Linux kernel can also be built with practically any distro out there. Having a need for a separate toolchain for building x86 on x86 is a bit overkill IMHO, at least for someone hacking on Seabios only infrequently like /me. Jan PS: Please avoid "mail-followup-to" in your replies, it messes up To/CC. -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Boot failure with MS-Dos 6.22 (due to bad BIOS build?)
Jan Kiszka wrote: > > Then I noticed, that if I rebuild the BIOS, from the exact same revision > > 1.6.3.1 revision that is committed in 'seabios' submodule in QEMU, then > > it works fine. So AFAICT, it is not the Seabios source code at fault, > > but rather the binary build we have commited to GIT. Should/can we rebuild > > the bios.bin in GIT ? > > Probably not without understanding what causes this strange > inconsistency. If Seabios builds without errors and then later on fails, > this is also a bug. > > Kevin, what information do you need to assess my tool chain? In the coreboot project we have more than 10 years of experience from distribution toolchains consistently being too broken to build a working coreboot image. The same problems apply to SeaBIOS. As you know, distribution toolchains are heavily patched, presumably to add some value to the distribution. The patches work fine when the toolchains should output userland binaries or the odd kernel. They fail frequently and in countless ways when used to produce bare metal binaries. Within coreboot it is much less effort to build an i386-elf cross toolchain than to mess with the hundreds if not thousands of issues in the distribution toolchains. The same applies to SeaBIOS of course. The script we use in coreboot is here: http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/crossgcc If you want to investigate and spend time on motivating distributions to unbreak their toolchains that's awesome, but be prepared to spend many weeks disassembling binaries and reverse engineering the toolchain. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Boot failure with MS-Dos 6.22 (due to bad BIOS build?)
On 2012-02-27 10:51, Daniel P. Berrange wrote: > I'm seeing current QEMU GIT fail to boot MS-Dos 6.22 with the following > crash: > > # qemu-system-x86_64 -fda ~/MS-DOS\ 6.22.img -m 1 -curses > iPXE v1.0.0-591-g7aee315 > iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 > PnP PMM++ C900 > > Booting from Floppy.. > .qemu: fatal: Trying to execute code outside > RAM or ROM at 0x0001000e > > EAX= EBX= ECX=c934 EDX=0068 > ESI=6801 EDI= EBP=002b ESP=fff5 > EIP= EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES =0040 0400 9300 > CS =f000 000f 9b00 > SS =9ec4 0009ec40 9300 > DS =9ec4 0009ec40 9300 > FS = 9300 > GS = 9300 > LDT= 8200 > TR = 8b00 > GDT= 000fcd78 0037 > IDT= 03ff > CR0=0010 CR2= CR3= CR4= > DR0= DR1= DR2= > DR3= > DR6=0ff0 DR7=0400 > CCS=00d0 CCD=0068 CCO=SARL > EFER= > FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 > FPR0= FPR1= > FPR2= FPR3= > FPR4= FPR5= > FPR6= FPR7= > XMM00= XMM01= > XMM02= XMM03= > XMM04= XMM05= > XMM06= XMM07= > Aborted > > > Git bisect blames this > > commit 41bd360325168b3c1db78eb7311420a1607d521f > Author: Jan Kiszka > Date: Sun Jan 15 17:48:25 2012 +0100 > > seabios: Update to release 1.6.3.1 > > User visible changes in seabios: > - Probe HPET existence (fix for -no-hpet) > - Probe PCI existence (fix for -machine isapc) > - usb: fix boot paths > > Signed-off-by: Jan Kiszka > > > I tried to bisect Seabios, but every revision in Seabios upstream works > fine. > > Then I noticed, that if I rebuild the BIOS, from the exact same revision > 1.6.3.1 revision that is committed in 'seabios' submodule in QEMU, then > it works fine. So AFAICT, it is not the Seabios source code at fault, > but rather the binary build we have commited to GIT. Should/can we rebuild > the bios.bin in GIT ? Probably not without understanding what causes this strange inconsistency. If Seabios builds without errors and then later on fails, this is also a bug. Kevin, what information do you need to assess my tool chain? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
