On 12/31/24 19:19, Rob Landley wrote:
On 12/23/24 07:05, Stafford Horne wrote:
The kernel config looks like it should have virt block device
support, but
...
-device virtio-blk-device,drive=d0 -drive
file=${DISK},id=d0,if=none,format=qcow2
-drive file=file.img,format=raw,id=hd0 -device virtio-blk-device,drive=hd0
My -device looks similar but -drive is file=file.img,format=raw,id=hd0
No idea what if= does? I haven't seemed to need it...
...
Thanks, I think this target is good for release. Now to figure out why
sh2eb network isn't working after the restore (it used to!). Nor is
microblaze's network...
My test harness appends -hda filename.img to the qemu command line,
which works for all the other targets, and is awkward to turn into
-device lots-of-stuff,file-filename.img,more-stuff inside a shell
script. (At best it's a special case parsing and rewriting qemu command
line plumbing to turn "generic" into an architecture-specific workaround.)
In THEORY I should be able to do something like:
root/or1k/run-qemu.sh -netdev user,id=net0 -device
virtio-net-device,netdev=net0 -device virtio-blk-device,drive=sd0 -hda
README
And just have extra arch setup that then accepts the generic appended to
it. But in practice that says:
qemu-system-or1k: -device virtio-blk-device,drive=sd0: Device needs
media, but drive is empty
Putting the -hda before the -device doesn't help. (And even if it did,
the result would barf if run _without_ -hda, which should also work.)
Having -hda by itself is accepted by qemu, but I don't know what
bus/driver gets added as a result (or1k kernel does not find it).
Rob
