On Thu, Jan 10, 2019 at 11:38:38PM +0100, Stefan Fritsch wrote:
> Hi,
>
> the diff below implements the virtio 1.0 standard in the kernel (0.9 keeps
> working, of course). It's not ready for commit, yet, but I would like some
> input.
>
> For the most part, the changes from 0.9 to 1.0 are not that big, but there
> are some notable differences. Since some headers are also used by vmd in
> userspace, how those things are handled in the kernel are also relevant to
> vmd.
>
> One change is that the number of feature bits is no longer limited to 32.
> This means in the long run, defining constants with values that have only
> the relevant feature bit set won't work anymore. So eventually, we will
> have to change the constants to contain the bit offsets instead. Then we
> can add some macros to make handling easier. This is what the attached
> diff does. However, in the nearer future 64 bits will be sufficient and
> another possibility is to continue as now and define features as uint64_t
> values. So, should we make the switch from "#define foo (1<<24)" to
> "#define foo 24" now or at some later time, when devices start using more
> than 64 bits?
>
> The biggest change in 1.0 is the way the resources are found and accessed
> for virtio_pci devices. This means that all the offsets for the generic
> configuration registers change between 0.9 and 1.0. One possibility would
> be to just define a second set of constants and use that for 1.0. However,
> since the register layout is documented as structs in the standard, I have
> tried something different and used some macros (CREAD/CWRITE in
> virtio_pci.c) and offsetof() magic to determine the register offset and
> width for an access. This has the advantage that the widths are
> automatically taken care of, whereas in the old style one has to manually
> pick the correct bus_dma_read/write_* function. However, I don't like the
> 0.9 code to use the one style and the 1.0 code to use the other style. I
> also don't know how suitable the offsetof hackery would be for vmd. So I
> would like input on which way you think is preferable?
>
> The diff does not implement 1.0 for virtio/mmio, yet. I hope that it does
> not break 0.9 virtio/mmio, but I have not tested that. So far I did not
> have success in running openbsd arm or aarch64 on qemu (openbsd panics).
> Any pointers about this?
Assuming a qcow2 image created by something along the lines of
'qemu-img create -f qcow2 root.qcow2 2g' miniroot64.fs from an arm64
snapshot and u-boot for qemu_arm64 from the u-boot-aarch64 package:
doas sh -c "qemu-system-aarch64 -runas $USER \
-M virt -serial stdio -m 1024 -cpu cortex-a57 \
-bios /usr/local/share/u-boot/qemu_arm64/u-boot.bin \
-device virtio-rng-device -netdev tap,id=net0 \
-device virtio-net-device,netdev=net0 \
-drive file=miniroot64.fs,if=none,id=drive0,format=raw \
-drive file=root.qcow2,if=none,id=drive1,format=qcow2 \
-device ich9-ahci,id=ahci \
-device ide-drive,drive=drive0,bus=ahci.0 \
-device ide-drive,drive=drive1,bus=ahci.1"
arm is similiar with no need to specify cpu.
