Am 06.08.2020 um 10:08 hat Philippe Mathieu-Daudé geschrieben:
> Without knowing the QEMU history, it is hard to relate QEMU objects
> with the hardware datasheet.
>
> For example, one naively expects:
>
> * a floppy disk is plugged / unplugged on the bus
>
> Wrong! QEMU floppy disks always sit on the bus. The block drives
> are plugged / unplugged on the disks, and the disks magically
> re-adapt their proprieties to match the block drive.
This is because what sits on the bus is not a floppy disk, but a floppy
drive. FloppyDrive is also what the type is called.
The disk is represented by the BlockDriverState (the actual image file)
that is inserted in the BlockBackend (which is logically part of the
drive).
> * a floppy controller has a fixed number of disks pluggable on the bus
>
> Wrong! QEMU floppy controllers have as much slots as the number of
> floppy drive provided when a machine is created. Then the ACPI table
> are generated and the number of slots can not be modified. So if you
> expect a dual slot controller being created with slot A and B, if
> the machine is created with a single drive attached, the controller
> will only have slot A created, and you will never be able to plug
> drive B without risking a mismatch in the ACPI tables.
Hm... I guess hotplugging floppy drives might actually have worked,
though I have never tried it on real hardware. I'm pretty sure it wasn't
an official feature, though, and ACPI tables certainly won't magically
change if you do this because (apart from polling, I guess) software has
no way to detect that you tinkered with the floppy cable. :-)
> * a floppy controller supporting 4 disks uses 2 buses
>
> Wrong! QEMU uses a single bus to plug the 4 disks.
But we don't even emulate floppy controllers that can have more than two
floppy drives:
$ x86_64-softmmu/qemu-system-x86_64 -device floppy -device floppy -device
floppy
qemu-system-x86_64: -device floppy: Can't create floppy unit 2, bus
supports only 2 units
This is checked in floppy_drive_realize(), so it applies to all
variants of the controller.
If you want more floppy drives, you have to create a second controller
(with a different iobase). Though I don't think I actually got this
working when I tried. I wasn't sure if the problem was the emulation or
the guest OSes (or SeaBIOS actually for DOS).
> As all these false assumptions are not obvious (we don't plug a disk,
> we plug a block drive into a disk, etc...), start documenting the QOM
> relationships with a simple ASCII schema.
Maybe be more specific to have: "floppy (drive)" and "blk (disk)".
Because the ASCII schema is actually true, though you seem to have
misunderstood what each item in it is supposed to represent.
Actually "blk (disk)" is not 100% accurate either because the drive
always has a BlockBackend present. It's really the BlockDriverState
inserted into the BlockBackend that is the disk.
In summary, to be honest, I believe since its qdevification, floppy is
one of the block devices that is modelled the best on the QOM + block
backend level. Only SCSI might be comparable, but IDE, virtio-blk and
usb-storage are a mess in comparison.
Kevin
> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org>
> ---
> hw/block/fdc.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/hw/block/fdc.c b/hw/block/fdc.c
> index 6944b06e4b..b109f37050 100644
> --- a/hw/block/fdc.c
> +++ b/hw/block/fdc.c
> @@ -47,6 +47,28 @@
> #include "qemu/module.h"
> #include "trace.h"
>
> +/*
> + * QOM relationship:
> + * =================
> + *
> + * +-------------------+
> + * | |
> + * isa/sysbus <--->| |
> + * | |
> + * irq/dma <----| fdc |
> + * |
> + * clk ---->| | +-+------+-+ +-+------+-+
> + * | | | | blk | | | | blk | |
> + * +--------+----------+ | | | | | | | |
> + * | | +------+ | | +------+ |
> + * | | | | |
> + * | | floppy | | floppy |
> + * | +----+-----+ +----+-----+
> + * | floppy-bus | |
> + * +------------------------v---------------v---
> + *
> + */
> +
> /********************************************************/
> /* debug Floppy devices */
>
> --
> 2.21.3
>
