Re: or1k -M virt -hda and net.

[Alex Bennée]

Rob Landley <rob@landley.net> writes:

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

Well if you want a simple drive command you need something. For example
on -M virt for aarch64:

  -drive  
driver=raw,file.driver=host_device,file.filename=/dev/zen-ssd2/trixie-arm64,discard=unmap

only really contains backend options. By default this will attach the
block device to the virtio-pci bus, see virt.c:

  mc->block_default_type = IF_VIRTIO;

The backend options might look a bit much, a simpler case with qcow2
would be:

  -drive driver=qcow2,file=trixie-x86_64.qcow2 

However if you don't have any default bus for your block devices you
must use -device/-blockdev pairs. It doesn't add much:

 -device virtio-scsi-pci \
 -device scsi-hd,drive=hd \
 -blockdev 
driver=raw,node-name=hd,file.driver=host_device,file.filename=/dev/zen-ssd2/trixie-arm64,discard=unmap
 \

So all I've added is the bus, a device and then linked them with the
drive/node-name ids.

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

You shouldn't need to micro manage bus details, you just need to link
the device to the backend via an id.

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

device and blockdev pairs are required. -drive attempts to do both in
one command line option.

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

We support a wide variety of boards some with fixed block device buses
and some with the ability to add stuff dynamically. While we certainly
could do better documenting the edge cases (patches welcome ;-) I'm not
sure its possible to come up with a generic command line that works
across all boards. That said any of the VirtIO enabled platforms (often
called virt) will have fairly similar command lines for adding devices
(modulo PCI/MMIO support).

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

Just put it in a script then. 

> (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?)

QEMU's command line reputation is not undeserved but it is at least
consistent with the modern composable options. If we can improve the
documentation then let us know:

  https://qemu.readthedocs.io/en/master/system/device-emulation.html

But expanding the use of automagical options is not really a long term
solution.

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

-append passes options to the kernel command line if you are doing a
direct kernel boot or your firmware supports direct kernel booting.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro