[Replying to various bits of this thread all at once]
* you have to specify which kind of virtio device you want in the
board model. In particular this means that for virtio-blk the user
has to say "-drive if=none,file=whatever.img,id=myimg
-global virtio-blk-mmio.drive=myimg" or the virtio-blk layer will
refuse to start, which is not at all userfriendly
This is pretty lame. I see two or three bugs here:
1) We're greating virtio devices unconditionally. Much better would be to
have devices be allocated as necessary. e.g. unless the user explicitly
requests otherwise, put the first device at a particular address, and
subsequent devices at sequential addresses. The guest OS can then easily probe
them to see which are present. I guess a null virtio device might make sense
to avoid accessing undefined memory regions.
For the vexpress board the logic tile site (0xc0000000) seems like a sensible
location. Your current choice of an area reserved by the southbridge seems
somewhat questionable.
2) virtio-blk fails if no drive is connected. I guess you could call this a
feature, which means you must fix (1). If not then I think it's reasonable
for hardcoded board devices should also use hardcoded drive IDs. i.e. we act
as if the user specified "-global virtio-blk-mmio.drive=virtio" or similar
3) "qemu -drive if=virtio" assmes you want PCI virtio. Either we consider
this an obsolete legacy option and document it as such, or fix it as part of
(1). In the latter case it's probably going to do the wrong thing on boards
that have both virtio-mmio and PCI (there are at least two correct answers).
[...]
Correct. Syborg virtio was something Paul Brook did bit is not an
"official" virtio transport as far as Linux or the spec is concerned.
I'm not sure what guest software uses the syborg virtio transport.
It is/was a virtual reference platform for SymbianOS. However since then the
Symbian Foundation got shot in the back of the head and the rest of Nokia
jumped ship to Windows, so I'd be surprised if anyone really cares about it.