On Mon 11 Feb 2019 03:51:33 PM CET, Vladimir Sementsov-Ogievskiy wrote: >>>> I think this was already discussed in the previous version of this >>>> patch: if you insert a copy-on-read filter here then all guest >>>> reads will copy the data from the backing chain, but you don't want >>>> to copy anything below the 'base' node, so the copy-on-read filter >>>> needs a 'base' parameter. >>>> >>> Before that, we still have the unresolved issue with getting the >>> filter as the 'base' input parameter. That happens sometimes because >>> the base is being searched by the file name, which is the same to >>> the one of the filter, rather than by the node name (!) >> >> I'm not sure if I understand. block-stream has 'base' and 'base-node' >> parameters, and in the first case you would convert the file name to >> a node name. >> >> stream_start() gets the BlockDriverState, not the file name, so why >> can't you get the node name from there and pass it to the >> copy-on-read filter? > > The problem is in the concept of "base" node. The code written in > manner that base is not changed during block job. However, job don't > own base and there is no guarantee that it will not change during the > job.
But if that's the case then we have a problem already, because 'base' is a member of StreamBlockJob and is used in the existing stream_run() code. So if there's a way to make 'base' disappear during the job (how?) then we could protect it with block_job_add_bdrv(). Berto
