Re: or1k -M virt -hda and net.

[BALATON Zoltan <balaton@eik.bme.hu>]

[-- Attachment #1: Type: text/plain, Size: 6035 bytes --]

On Tue, 7 Jan 2025, Rob Landley wrote:
> 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

You need '-drive if=none,id=hd0,format=raw,file=README' as a single option 
not split into two. With if=none -drive won't auto-create a device so you 
then also need a corresponding -device option for the drive that you seem 
to have already above. If you want -hda to work you may need something 
like commit d36b2f4e78 (hw/ppc/sam460ex: Support short options for adding 
drives) for the machine you use. In particular the MachineClass 
block_default_type field says what's the default interface that -drive and 
other short options should use (at least I think so, I'm no expert on this 
either but searching for it should at least point to where it's handled).

Regards,
BALATON Zoltan

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