Am 24.08.2026 um 13:41 hat Christian Quante geschrieben: > hw/block/fdc.c never calls block_acct_*, so a floppy drive stays at > zero in query-blockstats and "info blockstats" while IDE, ATAPI, SCSI, > virtio-blk, NVMe and xen-block all report their traffic. That is the > only interface through which QEMU reports drive activity, so a > front-end that shows per-drive activity LEDs -- the way 86Box does -- > can light up every bus except the floppy. > > The accounting is already set up for the drive: floppy_drive_realize() > reaches block_acct_setup() through blkconf_apply_backend_options(), and > -device floppy carries account-invalid, account-failed and > stats-intervals through DEFINE_BLOCK_PROPERTIES. The properties can be > set today, they just have nothing to act on. > > Wrap the five blk_pread()/blk_pwrite() calls in two helpers that > account for the transfer. The cookie lives on the stack: floppy I/O is > synchronous throughout, so it never outlives the call and there is no > device state to migrate, unlike IDE where the cookie sits in the device > because the transfer is asynchronous -- scsi-disk, nvme, ahci and > xen-block all keep it in their request state for the same reason. > > Measured with a boot sector that reads 18 sectors from A: and 16 from > C: and writes two back to each. The disk backend reports rd_ops=16 > rd_bytes=8192 wr_ops=2 wr_bytes=1024 either way, so the guest did the > same work in both runs; the floppy went from rd_ops=0 wr_ops=0 to > rd_ops=19 rd_bytes=9728 wr_ops=2 wr_bytes=1024 -- 19 reads being the > boot sector the BIOS pulls in plus the 18 the guest asks for. > > Signed-off-by: Christian Quante <[email protected]>
Thanks, applied to the block branch. Would you mind adding some assertions that we counted correctly to some existing I/O in fdc-test as a followup? Kevin
