On 09/08/2018 04:28 AM, Bin Meng wrote:
Hi Tuomas,
On Sat, Sep 8, 2018 at 7:14 AM Tuomas Tynkkynen <tuomas.tynkky...@iki.fi> wrote:
[...]
You can find my branch here:
https://github.com/dezgeg/u-boot/tree/virtio
It should work under qemu_arm64_defconfig as follows:
qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 512 \
-bios u-boot.bin -s -nographic \
-netdev user,id=net0 -device virtio-net-device,netdev=net0 \
-drive if=none,file=disk.img,id=disk0 \
-device virtio-blk-device,drive=disk0
I tried with Fedora-Server-netinst-aarch64-28-1.1.iso I had lying
around and letting it auto-boot worked fine.
Also interrupting the boot and doing 'virtio scan; dhcp' gets a
successful DHCP lease from QEMU's internal server.
Thank you for sharing your WIP. I just did a quick look and it seems
that you implemented the virtio uclass in a similar way like pci
uclass. My implementation is slightly different. I don't introduce
VIRTIO_GENERIC device and a complex driver matching logci like PCI. I
Yeah, VIRTIO_GENERIC ended up looking quite weird. It's not even used
normally, e.g. virtio-net doesn't end up using it at all:
=> dm tree
Class index Probed Driver Name
-----------------------------------------
virtio 31 [ + ] virtio_mmi |-- virtio_mmio@a003e00
eth 1 [ + ] virtio_net | `-- virtio_net
It does get used for virtio-blk though:
virtio 30 [ + ] virtio_mmi |-- virtio_mmio@a003c00
virtio_gen 0 [ + ] virtio_blk | `-- virtio_blk
blk 0 [ + ] virtblk | `-- virtio_blk.blk
But that is only because I couldn't make the block device (i.e.
the one with UCLASS_BLK) without introducing some device in the
middle. All of the functions like blk_create_device() seem to be
designed for the use cases of say, an AHCI controller having
multiple SATA ports or an SCSI device having multiple LUNs.
I guess the right thing to do would be to split blk_create_device()
so that it would be possible to have a tree like this:
virtio 30 [ + ] virtio_mmi |-- virtio_mmio@a003c00
blk 0 [ + ] virtio_blk | `-- virtio_blk
Then the need for UCLASS_VIRTIO_GENERIC would go away.
just did simple driver matching based on virtio device id. I wrote
some skeleton drivers to verify this can work with both virtio-mmio
and virtio-pci devices.
I took a brief look and these things still need work:
- Some of the virtio headers imported verbatim cause compiler
warnings because we don't disable strict aliasing.
- Architectures need to import various definitions from Linux.
At least PAGE_SIZE & PAGE_SHIFT and wmb() & rmb().
(currently there are just gross hacks around this)
- Feature negotiation (needed for virtio-net to be able to
set/get a MAC address) is not implemented yet.
- The virtio-pci transport is not implemented, only virtio-mmio.
- Error handling is missing in many places.
- Resource cleanup in some places, like virtio-net which needs to
remove live buffers from the RX virtqueue on shutdown and I haven't
looked into how to do that.
- Lots of small things like removing debug/commented out code, wrong
kerneldoc comments, dead/uneeded code etc. to be cleaned up.
Have fun and let me know if you have questions.
Thanks for all these details! I will try integrating some of your WIP
with mine. I think I can directly use the virtio-blk and virtio-net
drivers from your tree as a start.
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
