Re: or1k -M virt -hda and net.

[Rob Landley]

On 1/7/25 12:05, Alex Bennée wrote:
> Stafford Horne <shorne@gmail.com> writes:
> > I have not used -hda before, do you have it working with other targets?
> >
> > According to the qemu docs in qemu-options.hx. I see:
> >
> >      Use file as hard disk 0, 1, 2 or 3 image on the default bus of the
> >      emulated machine (this is for example the IDE bus on most x86 machines,
> >      but it can also be SCSI, virtio or something else on other target
> >      architectures). See also the :ref:`disk images` chapter in the System
> >      Emulation Users Guide.
> >
> > I think, since we don't have a "default" bus in openrisc this doesn't work so we
> > need to specify the -drive explictly.
> >
> > I checked the x86 machine code and confirm it seems to work like this.  There is
> > code in the system setup to look for hd* drives and wire them into IDE.  There
> > is no such code in openrisc.
>
> Yeah don't use -hdX as they are legacy options with a lot of default
> assumptions. As the docs say: 
> https://qemu.readthedocs.io/en/master/system/invocation.html#hxtool-1
>
>    The QEMU block device handling options have a long history and have
>    gone through several iterations as the feature set and complexity of
>    the block layer have grown. Many online guides to QEMU often reference
>    older and deprecated options, which can lead to confusion.

I want "a block device from this file" in a generic way that works the 
same across multiple architectures regardless of the board being 
emulated, where I only have to specify the file not explicitly 
micromanage bus plumbing details, and which is easy for a human to type 
from when explained over a voice call.

What's the alternative to -hda you suggest for that?

Can I do "./run-qemu.sh -drive file=blah.img" without the rest? Perhaps 
specify all the details in the script and then optionally add an extra 
argument at the end? I couldn't get that to work:

$ root/or1k/run-qemu.sh -netdev user,id=net0 -device 
virtio-net-device,netdev=net0 -drive format=raw,id=hd0 -device 
virtio-blk-device,drive=hd0 -drive file=README
qemu-system-or1k: -drive format=raw,id=hd0: A block device must be 
specified for "file"

Also, if you say -device and -drive but do NOT specify a file, qemu 
refuses to start. So I can't set the defaults but only optionally use 
them, the way -hda has defaults built into the image that don't cause a 
problem if I DON'T add a -hda argument to the command line.

>    Older options like -hda are essentially macros which expand into -drive
>    options for various drive interfaces.

Where the knowledge of "what this board needs in order to do that" is 
built into qemu rather than provided by the caller, yes.

> The original forms bake in a lot
>    of assumptions from the days when QEMU was emulating a legacy PC, they
>    are not recommended for modern configurations.

I'm building a kernel. It finds /dev/?da so I can mount it. That is my 
desired outcome.

I am attempting to get generic behavior out of multiple architectures, 
among other reasons so I can cross-test and package up "it fails on X, 
here's a build and test" to point package maintainers at.

"It natively builds under the emulator" is the easiest way to make that 
work, which is why https://landley.net/bin/toolchains/latest/ has a 
native.sqf for each cross.tar.xz.

wget system-image-arch.txz
wget toolchain.sqf
wget test.img

./run-emulator.sh -hda test.img -hdb toolchain.sqf

If I have to explain "-drive virtio-potato-walrus,inkpot=striated 
-device collect=striated,burbank-potato,ireland" at somebody whose 
domain expertise is xfce or something, the barrier to getting them to 
reproduce the issue I'm seeing is noticeably higher. If I have to MAKE a 
bespoke wrapper shell script for them with every bug report, the 
likelihood that it works differently for them than when I tried it is 
noticeably nonzero, and the likelihood of the issue going on my todo 
heap and never getting pursued upstream is also noticeably higher. Which 
is why I try to make generic tools...

(Making a _test_ script to demonstrate the issue is normal. If it's 
their project, usually they can tell if I typoed it and fix it up 
themselves because they know what I MEANT. But if I typo the setup for 
the virtual environment, or are missing a prerequisite package install, 
or they hit qemu version skew, or I said /bin/sh and theirs points to 
dash... Brick wall. It either works or it doesn't.)

(And when I have to set up the long version for a nightly cron job, and 
then when the test fails 6 months later and I look at it and go "huh? 
salad?" that's a bad 3am digression as well. And which is more likely to 
break from version skew during qemu version upgrades: two lines of 
micromanaging --longopts or -hda that gets adjusted by the maintainers?)

Rob

P.S. For some reason -hda grew an "I'm going to make the first block 
read-only just like loopback devices do because you can't be trusted" 
nag a few years back, but it's mostly yet more boot spam. I can tell the 
kernel to be quiet during boot, but never figured out the equivalent for 
qemu-system...