Re: or1k -M virt -hda and net.

[Alex Bennée]

Stafford Horne <shorne@gmail.com> writes:

> On Tue, Jan 07, 2025 at 05:56:52AM -0600, Rob Landley wrote:
>> 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.)
>
> Hi Rob,
>
> Sorry, from the laat email I was under the impression that you had everything
> working as expected.
>
>> 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).
>
> I am having a hard time understanding the use case.
>
> As you know I use the following to wire in the buildroot image which I turned
> into a qcow2 disk using my tool:
>
>   https://github.com/stffrdhrn/or1k-utils/blob/master/scripts/qemu-or1k-mkimg
>
>   -device virtio-blk-device,drive=d0 -drive file=${DISK},id=d0,format=qcow2
>
> But I think you want to use:
>
>   -device virtio-blk-device,drive=sd0 -hda XYZ
>
> 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.

  The most explicit way to describe disks is to use a combination of
  -device to specify the hardware device and -blockdev to describe the
  backend. The device defines what the guest sees and the backend
  describes how QEMU handles the data. It is the only guaranteed stable
  interface for describing block devices and as such is recommended for
  management tools and scripting.

  The -drive option combines the device and backend into a single
  command line option which is a more human friendly. There is however
  no interface stability guarantee although some older board models
  still need updating to work with the modern blockdev forms.

  Older options like -hda are essentially macros which expand into -drive
  options for various drive interfaces. 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.

>
> -Stafford

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro