This commit adds the VirtIO 9p device driver based on the VirtIO driver
stack in LK, `dev/virtio`. The driver supports a subset of 9P2000.L
protocol (https://github.com/chaos/diod/blob/master/protocol.md), which
is able to perform basic file operations (fread, fwrite, dirread, etc.).
The primary interface for sending and receiving the 9p messages is
`virtio_9p_rpc`, which is handy and scalable.
The driver is limited to communicate to the host with only one
outstanding 9p message per device due to the simplified driver design.
Basically that is enough for embedded environments when there is no
massive file IO.
Signed-off-by: Cody Wong <codycswong@google.com>
Add new feature bits for the net device
Since the new feature bits are >= 32, add support for reading higher
than 32bit feature words from the virtio mmio interface.
Disable IO and mem decoding around BAR enumation as described in the PCI
Local Bus specification. This behavior should be safer when messing
around BARs for BAR lengths.
Nothing fundamentally changed, just update to new feature bits and print
them at device detection time.
Try to negotiate the guest feature set as well, though nothing
fundamentally changes at this time.
In the non VM path the existing routine wouldn't subtract from len, so
the function would (properly) return bytes transferred instead of zero.
The wrapping code was written to assume 0 and not bytes transferred,
which seemed like a workaround for broken code. Change the inner routine
to always return bytes transferred and adjust wrapper routines
accordingly.
In the case of platforms where a bios or firmware has not already
assigned all the resources, do so. Requires the platform supply one or
more ranges of physical address space and IO that can be mapped into
BARs.
Handles iterating through bridges, computing the sizes of all the
peripherals downstream and rolling that up as well.
Wire them up on arm and riscv which need them. x86-pc does not, so dont
call it.
Also fix a few miscellaneous bugs, notably PCI not detecting 64bit bars
properly due to an off by one bit error.
Had to rearrange the proble logic somewhat, but now the bus manager will
assign consequtive bus numbers as it finds bridges and recursively
drills down to discover the entire bus structure.
Does not assign resources yet, but need to do this in the first pass
to find all of the devices before can figure out how much space they
occupy.
This fixes an infinite recursion where it was stepped into bridge a
bridge that has the secondary bus set to 0, which caused it to start
over and probe bus 0 until it blew the stack.
Better fix is to actually assign busses.
Probe the size first, and if that turns up anything, mark the bar as
valid, even if the address is set to 0. The address can be configured in
a later pass of the bus manager.
Also print the bars on boot.
Since probing the size of a BAR requires writing and reading back from
the address field, do it at probe time and cache the data instead of at
api time. This should avoid fouling up any mmio transactions in flight.
-Add a bus manager level, which is an object oriented walk of the pci
busses to build a per device object for later manipulation.
-Add features to enable MSI interrupts.
-Extend generic interrupt api to allow the platform to allocate vectors
for MSI interrupts.
-Rearrange a bit of the pc platform for the platform api changes.
-Add PC platform support for using the local apic to EOI MSI vectors.
-Fix up a few existing PCI drivers for small API changes.
-Add a few stubbed out routines for non PC platforms that use PCI.
Previous to now it had always relied on a custom patched gcc
and a custom sim. In the interim since the initial port went in
some time in 2015 GCC and QEMU have both officially picked up support
for the architecture and the machine that was emulated in the previous
emultor.
Using gcc 10.2 fix up the build and get it basically working. Timers
seem to not be working right but it's probably fairly easy to fix.
