Linux devices

[kiniry]

Enumerate here every Linux device that we are providing in CloudGFE, and cross-link to an issue that tracks progress on supporting said device.

• [x] #2 Ethernet
• [x] #7 UART
• [x] #1 Persistent Storage
• [ ] #72 Source of Randomness

[kiniry]

I'm leaving this unassigned for the moment and simply CCing folks who should be cognizant of this issue: @charlie-bluespec @rsnikhil @podhrmic @jameyhicks @dhand-galois @kiniry

[rsnikhil]

Work is in progress for AWSteria for VirtIO support, which will address the block device and Ethernet requirements. HW support is in place; studying the host-side C code to see what is needed and how to structure it in threads, etc.

[kiniry]

Given @dhand-galois's recent work on the RNG bridge from the host to the F1, we now have a quality source of randomness for FireSim-based platform variants. Was the VirtIO randomness device added to the Connectal platform variant? @jameyhicks

[rsnikhil]

I see excerpts in the current virtio code used in the Connectal setup, added by Jamey and/or Jessica, for an 'entropy' device, but I do not know its status. Alternatively, since can do remote reads/writes from Flute to be served by the host-side, which could be hooked up to a host-side solution.

[jrtc27]

It's working, just like any other device. Please make use of it, as it should just work, and is perhaps the simplest device to get working first, as it has no host-side I/O complications nor configuration required. If you're able to get detection and the queue processing working (the data inside the queue is unimportant, as the body and headers use the same DMA paths, so although you can't really tell if the body is correct I don't think it matters), the other devices should follow pretty much immediately (block device for sure, as TinyEMU handles the reads/writes, but network will require a thread to deal with the host-facing end of TinyEMU).

[kiniry]

Thanks for the update.