[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Outreachy project task: Adding QEMU block layer APIs resembling Linu
From: |
Stefan Hajnoczi |
Subject: |
Re: Outreachy project task: Adding QEMU block layer APIs resembling Linux ZBD ioctls. |
Date: |
Mon, 30 May 2022 12:21:58 +0100 |
On Mon, 30 May 2022 at 06:38, Damien Le Moal <Damien.LeMoal@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