| commit | d28fc4ef75321c5721004682e153bec8e59682a7 | [log] [tgz] |
|---|---|---|
| author | Venkatesh Srinivas <venkateshs@google.com> | Wed Jan 23 22:28:47 2019 +0000 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Wed Jan 23 23:59:08 2019 +0000 |
| tree | 5734f639dd7d2700eede8a96ffe34360c9984922 | |
| parent | a989ca2d02f8ded2bb4a7cde800fd85519df7181 [diff] |
[virtio] virtio-scsi driver
virtio-scsi is a storage controller that bridges a virtio bus to
a SCSI bus or busses; each bus may have zero to many storage
targets/Logical Units attached. virtio-scsi supports a rich per-target
command set, asynchronous event notification for disk
attach/detach/resize, 'task management' (cancellation/target reset), and
command queueing.
virtio-scsi is the default storage controller in GCE.
Currently this driver is just a skeleton - it probes every possible SCSI
target with a TEST UNIT READY command and allocates a scsi::Disk bridge
between the zircon block protocol and SCSI layer. Subsequent commits
will implement the translation in scsi::Disk, break up ExecuteCommandSync
into a call to queue a request with a callback and a mechanism to
wait for a command, and complete and pull the probe sequence from
scsi.cpp to scsilib.cpp.
Tested:
1) Created GCE instance w:
$ fx set x64 --args=kernel_cmdline_files=\[\"//scripts/gce/kernel-cmdline.txt\"\]
$ fx full-build
$ fx gce create-fuchsia-image && fx gce create-instance
<connected to serial port>
Saw:
[00007.306] 02580.02790> scsi-disk-1-0: added
[00007.316] 02580.02603> block: device 'scsi-disk-1-0': invalid block size: 0
[00007.316] 02580.02603> devhost[00:03.0/virtio-scsi/scsi-disk-1-0] bind driver '/boot/driver/block.so' failed: -2
[00007.318] 01102.01115> devcoord: rpc: bind-driver 'scsi-disk-1-0' status -2
(size zero is expected.)
2) Ran dm dump:
...
[00:03.0] pid=2012 /boot/driver/bus-pci.so
<00:03.0> pid=2921 /boot/driver/bus-pci.proxy.so
[virtio-scsi] pid=2921 /boot/driver/virtio.so
...
3) Attached four scsi disks, rebooted, saw:
[00007.431] 02572.02595> virtual zx_status_t virtio::ScsiDevice::Init(): entry
[00007.458] 02572.02756> scsi-disk-1-0: status=0
[00007.463] 02572.02756> scsi-disk-2-0: status=0
[00007.470] 02572.02756> scsi-disk-3-0: status=0
[00007.476] 02572.02756> scsi-disk-4-0: status=0
...
[00027.252] 01102.01115> devcoord: device 0x45b762509e00 name='00:04.0' disconnected!
[00027.261] 01102.01115> devcoord: device 0x45b762509c00 name='00:03.0' disconnected!
[00027.268] 01102.01115> devcoord: device 0x45b762509b00 name='00:01.3' disconnected!
[00027.270] 01102.01115> devcoord: device 0x45b762509a00 name='00:01.0' disconnected!
[00027.271] 01102.01115> devcoord: device 0x45b762509900 name='00:00.0' disconnected!
ZX-2314
Change-Id: Ic361da103d63bf3e0dad09d479340d6ca4d034e2
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
A read-only mirror of the code is present at: https://github.com/fuchsia-mirror/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.