[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Tuomas Tynkkynen]

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 at 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 at a003e00
  eth          1  [ + ]   virtio_net  |   `-- virtio_net

It does get used for virtio-blk though:

  virtio      30  [ + ]   virtio_mmi  |-- virtio_mmio at 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 at 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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>