femu/zns: write caches per open zone, and two fixes on the cache path

[wnsah814]

Description

The ZNS write cache stages one zone's partial stripe, so a device needs one cache per zone the host may be writing at the same time. Three things on that path made the emulated device collapse under concurrent sequential writers, which a real ZNS SSD does not do (a WD ZN540 keeps its throughput flat up to its open limit of 14 zones):

1. The count was hard-wired to 3. zns_num_wc now sets it; left at 0 it follows zns_max_open, and stays 3 when that is unlimited, so existing configurations are unchanged. Real devices bound these per-zone buffers with the open-zone limit (Bjørling et al., ATC '21, §3.1).
2. The free-cache scan skipped cache 0. It started at index 1 with cache 0 as the initial candidate, so an empty cache 0 was never taken while any other cache was in use: the device served one writer fewer than it had caches, and the third concurrent zone already evicted on every write.
3. A flush of a partial cache burned a whole stripe. An evicted cache holding a few LPNs still walked every plane and page of the stripe, so one 4 KiB write consumed 2 planes × 3 pages, the zone's blocks ran out of pages long before the zone was full, later LPNs were mapped past their block, and reads of them failed valid_ppa() and completed with no NAND time at all. The flush now stops once the cache's LPNs are placed (the last page is still padded, as a real program is).

8 ch × 4 chips × 2 planes, TLC, tR 65 µs / tPROG 450 µs; N writers, one zone each, 4 KiB sequential, psync QD1, 96 MiB per writer; then 4 KiB random reads of the first writer's zone for 10 s. Read latency below tR means the read never reached the NAND model.

writers	master: write IOPS / read µs	this branch, defaults (3 caches)	this branch, zns_max_open=14
2	103,044 / 75.6	112,476 / 75.5	105,251 / 76.2
3	36,919 / 60.2	162,040 / 76.9	160,278 / 75.6
4	13,333 / 24.5	19,355 / 62.2	206,088 / 75.5
8	19,718 / 20.5	24,524 / 50.2	274,592 / 74.9

With the defaults the third writer no longer thrashes (fix 2) and a thrashing device no longer reads faster than tR (fix 3); with the cache count following the open limit there is no thrash to 8 writers.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Performance improvement
• Code refactoring

Testing

• I have tested my changes locally
• I have added tests that prove my fix is effective or that my feature works
• All existing tests pass
• I have tested across multiple FEMU modes (if applicable)

FEMU Modes Tested

• BlackBox SSD (BBSSD)
• WhiteBox SSD (OCSSD)
• Zoned Namespace SSD (ZNSSD)
• NoSSD
• Not applicable

Platform Testing

• Ubuntu 20.04/22.04
• Other distributions (specify): ___________
• Build verification completed

Checklist

• My code follows QEMU coding standards
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new compiler warnings
• I have updated documentation if necessary
• No trailing whitespace or C++ style comments in C files

[huaicheng]

Thanks, @wnsah814 — merged. The cache-0 scan and the partial-flush fix are real bugs, and tying the cache count to the open-zone limit is the right default.

One follow-up I'll add separately: zns_num_wc isn't bounded, so a very large value aborts QEMU at realize; I'll cap it at the zone count, since a cache beyond that can never be used.