virtio-devices: block: Fix writeback mode update flow - #7949
Conversation
| @@ -1097,7 +1097,8 @@ impl VirtioDevice for Block { | |||
| // Recompute the barrier size from the queues that are actually activated. | |||
| self.common.paused_sync = Some(Arc::new(Barrier::new(queues.len() + 1))); | |||
|
|
|||
| self.update_writeback(); | |||
| let writeback = self.is_writeback_enabled(true); | |||
There was a problem hiding this comment.
It's not easy to see in the refactoring but this breaks migration. As it overwrites the writeback value (previously it would be recalculated from the features.)
There was a problem hiding this comment.
Good catch, thanks! The activate path was hardcoding desired = true instead of reading from the restored config. Fixed by using self.config.writeback == 1 as the desired value, so on migration restore it preserves whatever the guest had set, and on fresh init it still defaults to writeback since the constructor sets config.writeback = 1.
There was a problem hiding this comment.
It's not easy to see in the refactoring but this breaks migration.
thanks for catching that! Since yesterday one of our customers projects is in production and we must not break live migration anymore (we have internal testing for that and working on live migration protocol versioning for these things).
There was a problem hiding this comment.
Good to know about the production constraint. I was considering adding a test for this, however a unit test wouldn't be sufficient for this. A targeted integration test would need a guest cooperation, especially a virtio driver that toggles WCE, which doesn't seem trivial to set up. So realistically, the existing snapshot/restore tests would catch the broken serialization or misbehavior after migration.
Thanks
There was a problem hiding this comment.
For the record: live migration is allowed to break between versions in CHV's documentation (until we declare production readiness). But it would be great avoid hidden changes where possible
There was a problem hiding this comment.
Agreed. This patch targets virtio spec compliance for the block writeback mode, and migration was not in scope. But the serialized config is preserved now as before. And with the production constraint, we should probably adopt a more migration aware development mindset going forward.
Thanks
There was a problem hiding this comment.
For the record: live migration is allowed to break between versions in CHV's documentation (until we declare production readiness). But it would be great avoid hidden changes where possible
We try very very hard not to. I think we're still working with up to v38.
There was a problem hiding this comment.
thanks for catching this @rbradford. Also thanks @weltling for fixing this.
Virtio v1.2 says that if CONFIG_WCE is negotiated but FLUSH is not, the device must initialize writeback to 0. It also says that if CONFIG_WCE was not negotiated but FLUSH was, the driver should assume presence of a writeback cache. Introduce a pure is_writeback_enabled helper and a set_writeback_mode helper. This makes the two call flows explicit: * write_config resolves the guest requested mode against the negotiated features before storing it back * activate starts from the default writeback preference and then resolves it against the negotiated features * reset restores the initial writeback state This keeps the config space value and the runtime writeback flag in sync and makes the spec driven fallback easier to follow. Signed-off-by: Anatol Belski <[email protected]>
6e50a27 to
a74ee1f
Compare
Virtio v1.2 says that if CONFIG_WCE is negotiated
but FLUSH is not, the device must initialize writeback to 0. It also says that if CONFIG_WCE was not negotiated but FLUSH was, the driver should assume presence of a writeback cache.
Introduce a pure is_writeback_enabled helper and a set_writeback_mode helper. This makes the two call flows explicit:
This keeps the config space value and the runtime writeback flag in sync and makes the spec driven fallback easier to follow.