On Mon, 30 May 2022 at 06:38, Damien Le Moal <damien.lem...@wdc.com> wrote: > On 2022/05/30 14:09, Sam Li wrote: > Once you have an API working and the ability to execute all zone operations > from > a guest, you can then work on adding the more difficult bits: supporting the > zone append operation will require tracking the write pointer position and > state > of the device sequential zones. For that, the zone information will need the > zone capacity and write pointer position of all zones. The zone state may not > be > necessary as you can infer the empty and full states from the zone capacity > and > zone write pointer position. States such as explicit/implicit open, closed, > read-only and offline do not need to be tracked. If an operation cannot be > executed, the device will fail the io on the host side and you can simply > propagate that error to the guest. > > See the Linux kernel sd_zbc driver and its emulation of zone append operations > for inspiration: drivers/scsi/sd_zbc.c. Looking at that code (e.g. > sd_zbc_prepare_zone_append()), you will see that the only thing being tracked > is > the write pointer position of zones (relative to the zone start sector). The > state is inferred from that value, indicating if the zone can be written (it > is > not full) or not (the zone is full).
It sounds like QEMU BlockDrivers need to maintain state? I haven't thought this through but the guest probably has some state and the device below QEMU also has state. Can QEMU just invoke the BLK*ZONE ioctls on behalf of the guest without maintaining it's own state? Stefan
