[PATCH] hw/block/fdc: account for read and write requests

[PATCH] hw/block/fdc: account for read and write requests

[Christian Quante]

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 <christian@quante.one>
---
 hw/block/fdc.c | 52 +++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 41 insertions(+), 11 deletions(-)

diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 1178b959a6..41776af6a0 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -222,6 +222,42 @@ static int fd_offset(FDrive *drv)
     return fd_sector(drv) << BDRV_SECTOR_BITS;
 }
 
+/* Reads the sector at the current position and accounts for the request */
+static int fd_read_sector(FDrive *drv, uint8_t *buf)
+{
+    BlockAcctStats *stats = blk_get_stats(drv->blk);
+    BlockAcctCookie acct;
+    int ret;
+
+    block_acct_start(stats, &acct, BDRV_SECTOR_SIZE, BLOCK_ACCT_READ);
+    ret = blk_pread(drv->blk, fd_offset(drv), BDRV_SECTOR_SIZE, buf, 0);
+    if (ret < 0) {
+        block_acct_failed(stats, &acct);
+    } else {
+        block_acct_done(stats, &acct);
+    }
+
+    return ret;
+}
+
+/* Writes the sector at the current position and accounts for the request */
+static int fd_write_sector(FDrive *drv, const uint8_t *buf)
+{
+    BlockAcctStats *stats = blk_get_stats(drv->blk);
+    BlockAcctCookie acct;
+    int ret;
+
+    block_acct_start(stats, &acct, BDRV_SECTOR_SIZE, BLOCK_ACCT_WRITE);
+    ret = blk_pwrite(drv->blk, fd_offset(drv), BDRV_SECTOR_SIZE, buf, 0);
+    if (ret < 0) {
+        block_acct_failed(stats, &acct);
+    } else {
+        block_acct_done(stats, &acct);
+    }
+
+    return ret;
+}
+
 /* Seek to a new position:
  * returns 0 if already on right track
  * returns 1 if track changed
@@ -1644,8 +1680,7 @@ int fdctrl_transfer_handler(void *opaque, int nchan, int dma_pos, int dma_len)
         if (fdctrl->data_dir != FD_DIR_WRITE ||
             len < FD_SECTOR_LEN || rel_pos != 0) {
             /* READ & SCAN commands and realign to a sector for WRITE */
-            if (blk_pread(cur_drv->blk, fd_offset(cur_drv), BDRV_SECTOR_SIZE,
-                          fdctrl->fifo, 0) < 0) {
+            if (fd_read_sector(cur_drv, fdctrl->fifo) < 0) {
                 FLOPPY_DPRINTF("Floppy: error getting sector %d\n",
                                fd_sector(cur_drv));
                 /* Sure, image size is too small... */
@@ -1672,8 +1707,7 @@ int fdctrl_transfer_handler(void *opaque, int nchan, int dma_pos, int dma_len)
 
             k->read_memory(fdctrl->dma, nchan, fdctrl->fifo + rel_pos,
                            fdctrl->data_pos, len);
-            if (blk_pwrite(cur_drv->blk, fd_offset(cur_drv), BDRV_SECTOR_SIZE,
-                           fdctrl->fifo, 0) < 0) {
+            if (fd_write_sector(cur_drv, fdctrl->fifo) < 0) {
                 FLOPPY_DPRINTF("error writing sector %d\n",
                                fd_sector(cur_drv));
                 fdctrl_stop_transfer(fdctrl, FD_SR0_ABNTERM | FD_SR0_SEEK, 0x00, 0x00);
@@ -1756,9 +1790,7 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
                                    fd_sector(cur_drv));
                     return 0;
                 }
-            if (blk_pread(cur_drv->blk, fd_offset(cur_drv), BDRV_SECTOR_SIZE,
-                          fdctrl->fifo, 0)
-                < 0) {
+            if (fd_read_sector(cur_drv, fdctrl->fifo) < 0) {
                 FLOPPY_DPRINTF("error getting sector %d\n",
                                fd_sector(cur_drv));
                 /* Sure, image size is too small... */
@@ -1843,8 +1875,7 @@ static void fdctrl_format_sector(FDCtrl *fdctrl)
     }
     memset(fdctrl->fifo, 0, FD_SECTOR_LEN);
     if (cur_drv->blk == NULL ||
-        blk_pwrite(cur_drv->blk, fd_offset(cur_drv), BDRV_SECTOR_SIZE,
-                   fdctrl->fifo, 0) < 0) {
+        fd_write_sector(cur_drv, fdctrl->fifo) < 0) {
         FLOPPY_DPRINTF("error formatting sector %d\n", fd_sector(cur_drv));
         fdctrl_stop_transfer(fdctrl, FD_SR0_ABNTERM | FD_SR0_SEEK, 0x00, 0x00);
     } else {
@@ -2270,8 +2301,7 @@ static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
         if (pos == FD_SECTOR_LEN - 1 ||
             fdctrl->data_pos == fdctrl->data_len) {
             cur_drv = get_cur_drv(fdctrl);
-            if (blk_pwrite(cur_drv->blk, fd_offset(cur_drv), BDRV_SECTOR_SIZE,
-                           fdctrl->fifo, 0) < 0) {
+            if (fd_write_sector(cur_drv, fdctrl->fifo) < 0) {
                 FLOPPY_DPRINTF("error writing sector %d\n",
                                fd_sector(cur_drv));
                 break;
-- 
2.53.0

Re: [PATCH] hw/block/fdc: account for read and write requests

[Christian Quante]

Gentle ping.

The patch still applies cleanly on master (209b2afaface) and fdc-test
passes with it: 16 ok, 1 skipped without --enable-asan.

Thanks,
Christian

Re: [PATCH] hw/block/fdc: account for read and write requests

[John Snow]

Is anyone looking at this, or should I be investigating it?

--js

On Fri, Sep 11, 2026 at 10:54 AM Christian Quante <christian@quante.one> wrote:
>
> Gentle ping.
>
> The patch still applies cleanly on master (209b2afaface) and fdc-test
> passes with it: 16 ok, 1 skipped without --enable-asan.
>
> Thanks,
> Christian
>

Re: [PATCH] hw/block/fdc: account for read and write requests

[Kevin Wolf]

Am 15.09.2026 um 16:30 hat John Snow geschrieben:
> Is anyone looking at this, or should I be investigating it?

I just returned from vacation, so a few things have piled up. Feel free
to have a look, but if you won't, I'll get to it in a while.

Kevin

> --js
> 
> On Fri, Sep 11, 2026 at 10:54 AM Christian Quante <christian@quante.one> wrote:
> >
> > Gentle ping.
> >
> > The patch still applies cleanly on master (209b2afaface) and fdc-test
> > passes with it: 16 ok, 1 skipped without --enable-asan.
> >
> > Thanks,
> > Christian
> >
> 

Re: [PATCH] hw/block/fdc: account for read and write requests

[Kevin Wolf]

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 <christian@quante.one>

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