| 1 | ============= |
| 2 | zoned-storage |
| 3 | ============= |
| 4 | |
| 5 | Zoned Block Devices (ZBDs) divide the LBA space into block regions called zones |
| 6 | that are larger than the LBA size. They can only allow sequential writes, which |
| 7 | can reduce write amplification in SSDs, and potentially lead to higher |
| 8 | throughput and increased capacity. More details about ZBDs can be found at: |
| 9 | |
| 10 | https://zonedstorage.io/docs/introduction/zoned-storage |
| 11 | |
| 12 | 1. Block layer APIs for zoned storage |
| 13 | ------------------------------------- |
| 14 | QEMU block layer supports three zoned storage models: |
| 15 | - BLK_Z_HM: The host-managed zoned model only allows sequential writes access |
| 16 | to zones. It supports ZBD-specific I/O commands that can be used by a host to |
| 17 | manage the zones of a device. |
| 18 | - BLK_Z_HA: The host-aware zoned model allows random write operations in |
| 19 | zones, making it backward compatible with regular block devices. |
| 20 | - BLK_Z_NONE: The non-zoned model has no zones support. It includes both |
| 21 | regular and drive-managed ZBD devices. ZBD-specific I/O commands are not |
| 22 | supported. |
| 23 | |
| 24 | The block device information resides inside BlockDriverState. QEMU uses |
| 25 | BlockLimits struct(BlockDriverState::bl) that is continuously accessed by the |
| 26 | block layer while processing I/O requests. A BlockBackend has a root pointer to |
| 27 | a BlockDriverState graph(for example, raw format on top of file-posix). The |
| 28 | zoned storage information can be propagated from the leaf BlockDriverState all |
| 29 | the way up to the BlockBackend. If the zoned storage model in file-posix is |
| 30 | set to BLK_Z_HM, then block drivers will declare support for zoned host device. |
| 31 | |
| 32 | The block layer APIs support commands needed for zoned storage devices, |
| 33 | including report zones, four zone operations, and zone append. |
| 34 | |
| 35 | 2. Emulating zoned storage controllers |
| 36 | -------------------------------------- |
| 37 | When the BlockBackend's BlockLimits model reports a zoned storage device, users |
| 38 | like the virtio-blk emulation or the qemu-io-cmds.c utility can use block layer |
| 39 | APIs for zoned storage emulation or testing. |
| 40 | |
| 41 | For example, to test zone_report on a null_blk device using qemu-io is:: |
| 42 | |
| 43 | $ path/to/qemu-io --image-opts -n driver=host_device,filename=/dev/nullb0 -c "zrp offset nr_zones" |
| 44 | |
| 45 | To expose the host's zoned block device through virtio-blk, the command line |
| 46 | can be (includes the -device parameter):: |
| 47 | |
| 48 | -blockdev node-name=drive0,driver=host_device,filename=/dev/nullb0,cache.direct=on \ |
| 49 | -device virtio-blk-pci,drive=drive0 |
| 50 | |
| 51 | Or only use the -drive parameter:: |
| 52 | |
| 53 | -driver driver=host_device,file=/dev/nullb0,if=virtio,cache.direct=on |
| 54 | |
| 55 | Additionally, QEMU has several ways of supporting zoned storage, including: |
| 56 | (1) Using virtio-scsi: --device scsi-block allows for the passing through of |
| 57 | SCSI ZBC devices, enabling the attachment of ZBC or ZAC HDDs to QEMU. |
| 58 | (2) PCI device pass-through: While NVMe ZNS emulation is available for testing |
| 59 | purposes, it cannot yet pass through a zoned device from the host. To pass on |
| 60 | the NVMe ZNS device to the guest, use VFIO PCI pass the entire NVMe PCI adapter |
| 61 | through to the guest. Likewise, an HDD HBA can be passed on to QEMU all HDDs |
| 62 | attached to the HBA. |