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

[Bin Meng]

Hi Tuomas,

On Mon, Sep 10, 2018 at 8:16 AM Tuomas Tynkkynen
<tuomas.tynkkynen at iki.fi> wrote:
>
> 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.

I used another way to do this, by not calling blk_create_device API
and some other changes. I now get the virtio-blk driver working with
my uclass implementation. Stay tuned :)

>
> > 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