Re: [Qemu-devel] Block Filters

[Fam Zheng]

On Tue, 09/03 18:24, Benoît Canet wrote:
> 
> Hello list,
> 
> I am thinking about QEMU block filters lately.
> 
> I am not a block.c/blockdev.c expert so tell me what you think of the 
> following.
> 
> The use cases I see would be:
> 
> -$user want to have some real cryptography on top of qcow2/qed or another
> format.
>  snapshots and other block features should continue to work
> 
> -$user want to use a raid like feature like QUORUM in QEMU.
>  other features should continue to work
> 
> -$user want to use the future SSD deduplication implementation with metadata 
> on
> SSD and data on spinning disks.
>  other features should continue to work
> 
> -$user want to I/O throttle one drive of his vm.
> 
> -$user want to do Copy On Read
> 
> -$user want to do a combination of the above
> 
> -$developer want to make the minimum of required steps to keep changes small
> 
> -$developer want to keep user interface changes for later
> 
> Lets take a example case of an user wanting to do I/O throttled encrypted 
> QUORUM
> on top of QCOW2.
> 
> Assuming we want to implement throttle and encryption as something remotely
> being like a block filter this makes a pretty complex BlockDriverState tree.
> 
> The tree would look like the following:
> 
>                     I/O throttling BlockDriverState (bs)
>                                |
>                                |
>                                |
>                                |
>                     Encryption BlockDriverState (bs)
>                                |
>                                |
>                                |
>                                |
>                     Quorum BlockDriverState (bs)
>                    /           |           \
>                   /            |            \
>                  /             |             \
>                 /              |              \
>             QCOW2 bs       QCOW2 b s       QCOW2 bs
>                |               |               |
>                |               |               |
>                |               |               |
>                |               |               |
>             RAW bs         RAW bs           RAW bs
> 
> An external snapshot should result in a tree like the following.
>                     I/O throttling BlockDriverState (bs)
>                                |
>                                |
>                                |
>                                |
>                     Encryption BlockDriverState (bs)
>                                |
>                                |
>                                |
>                                |
>                     Quorum BlockDriverState (bs)
>                    /           |           \
>                   /            |            \
>                  /             |             \
>                 /              |              \
>             QCOW2 bs       QCOW2 bs         QCOW2 bs
>                |               |               |
>                |               |               |
>                |               |               |
>                |               |               |
>             QCOW2 bs       QCOW2 bs         QCOW2 bs
>                |               |               |
>                |               |               |
>                |               |               |
>                |               |               |
>             RAW bs         RAW bs           RAW bs
> 
> In the current state of QEMU we can code some block drivers to implement this
> tree.
> 
> However when doing operations like snapshots blockdev.c would have no real 
> idea
> of what should be snapshotted and how. (The 3 top bs should be kept on top)
> 
> Moreover it would have no way to manipulate easily this tree of 
> BlockDriverState
> has each one is encapsulated in it's parent.
> 
> Also there no generic way to tell the block layer that two or more 
> BlockDriverState
> are siblings.
> 
> The current mail is here to propose some additionals structures in order to 
> cope
> with these problems.
> 
> The overall strategy of the proposed structures is to push out the
> BlockDriverStates relationships out of each BlockDriverState.
> 
> The idea is that it would make it easier for the block layer to manipulate a
> well known structure instead of being forced to enter into each 
> BlockDriverState
> specificity.
> 
> The first structure is the BlockStackNode.
> 
> The BlockStateNode would be used to represent the relationship between the
> various BlockDriverStates
> 
> struct BlockStackNode {
>     BlockDriverState *bs;  /* the BlockDriverState holded by this node */
> 
>     /* this doubly linked list entry points to the child node and the parent
>      * node
>      */
>     QLIST_ENTRY(BlockStateNode) down;
> 
>     /* This doubly linked list entry point to the siblings of this node
>      */
>     QLIST_ENTRY(BlockStateNode) siblings;
> 
>     /* a hash or an array of the sibbling of this node for fast access
>      * should be recomputed when updating the tree */
>     QHASH_ENTRY<BlockStateNode, index> sibblings_hash;
> }
> 
> The BlockBackend would be the structure used to hold the "drive" the guest 
> use.
> 
> struct BlockBackend {
>     /* the following doubly linked list header point to the top BlockStackNode
>      * in our case it's the one containing the I/O throttling bs
>      */
>     QLIST_HEAD(, BlockStateNode) block_stack_head;
>     /* this is a pointer to the topest node below the block filter chain
>      * in our case the first QCOW2 sibling
>      */
>     BlockStackNode *top_node_below_filters;
> }
> 
> 
> Updated diagram:
> 
> (Here bsn means BlockStacknode)
> 
>     ------------------------BlockBackend
>     |                             |
>     |                          block_stack_head
>     |                             |
>     |                             |
>     |                       I/O throttling BlockStackNode (contains it's bs)
>     |                             |
>     |                            down
>     |                             |
>     |                             |
> top_node_below_filter     Encryption BlockStacknode (contains it's bs)
>     |                             |
>     |                            down
>     |                             |
>     |                             |
>     |                Quorum BlockStackNode (contain's it's bs)
>     |               /
>     |             down
>     |             /               
>     |            /     S              S
>     ------  QCOW2 bsn--i---QCOW2 bsn--i------ QCOW2 bsn (each bsn contains a 
> bs)
>                |       b       |      b         |
>              down      l      down    l        down
>                |       i       |      i         |
>                |       n       |      n         |
>                |       g       |      g         |
>                |       s       |      s         |
>                |               |                |
>             RAW bsn         RAW bsn           RAW bsn  (each bsn contains a 
> bs)
> 
> 
> Block driver point of view:
> 
> to construct the tree each BlockDriver would have some utility functions 
> looking
> like.
> 
> bdrv_register_child_bs(bs, child_bs, int index);
> 
> multiples calls to this function could be done to register multiple siblings
> childs identified by their index.
> 
> This way something like quorum could register multiple QCOW2 instances.
> 
> driver would have a
> BlockDriverSTate *bdrv_access_child(bs, int index);
> 
> to access their childs.
> 
> These functions can be implemented without the driver knowing about
> BlockStateNodes using container_of.
> 
> blockdev point of view: (here I need your help)
> 
> When doing a snapshot blockdev.c would access
> BlockBackend->top_node_below_filter and make a snapshot of the bs contained in
> this node and it's sibblings.
> 
Since BlockDriver.bdrv_snapshot_create() is an optional operation, blockdev.c
can navigate down the tree from top node, until hitting some layer where the op
is implemented (the QCow2 bs), so we get rid of this top_node_below_filter
pointer.

Is this the only use case of top_node_below_filter?

Fam

> After each individual snapshot the linked lists and the hash/arrays would be
> updated to point to the new top bsn.
> The snapshot operation can be done without violating any of the top block
> filter BlockDriverState.
> 
> What do you think of this idea ?
> How this would fit in block.c/blockdev.c ?
> 
> Best regards
> 
> Benoît