qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Question about bdrv_co_invalidate_cache


From: Kevin Wolf
Subject: Re: [Qemu-devel] Question about bdrv_co_invalidate_cache
Date: Tue, 2 Jul 2019 10:07:35 +0200
User-agent: Mutt/1.11.3 (2019-02-01)

Am 01.07.2019 um 18:42 hat Yury Kotov geschrieben:
> Hi,
> 
> I just want to clarify the purpose of bdrv_co_invalidate_cache callback.
> IIUC on of the purposes of this callback is to "activate" BDRV (opposite of 
> the
> bdrv_inactivate callback) on migration end, right?
> 
> E.g, if we have a custom BDRV which is backed by some network block storage 
> with
> exclusive mount then on migration end bdrv_inactivate callback have to unmount
> this storage and bdrv_co_invalidate_cache have to mount it.
> 
> I'm not sure because of the name of bdrv_co_invalidate_cache callback. It 
> looks
> like something that can be called in very different context, not only 
> migration
> (may be not now, but in the future).
> 
> If there is another approach for my example, tell me about it, please.
> We have such custom BDRV with exclusive mount and want to realize migration
> support correctly.

Yes, you can consider bdrv_co_invalidate_cache/bdrv_co_inactivate a pair
of functions to activate/inactivate images. I think all of their callers
are related to migration currently, but it shouldn't make a difference
for you.

The name .bdrv_co_invalidate_cache hints at what usually needs to be
done on migration completion: Any previously read (meta)data must be
invalidated because the migration source (or more genereally: a second
process where the image was activated) may still have written to the
image.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]