On 09/08/2018 04:28 AM, Bin Meng wrote:
Hi Tuomas,
On Sat, Sep 8, 2018 at 7:14 AM Tuomas Tynkkynen tuomas.tynkkynen@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