[PATCH v2 00/10] qemu: add option to process offloaded legacy blockjob event ealier

Peter Krempa pkrempa at redhat.com
Fri Dec 4 15:11:35 UTC 2020


On Fri, Nov 13, 2020 at 09:53:28 +0300, Nikolay Shirokovskiy wrote:
> This is successor to [1] but I changed the subject as in the review the patch
> 'qemu: sync backing chain update in virDomainGetBlockJobInfo' was not
> considered good one from design POV. However I think the basic patch is helpful
> to address similar issues. Look at [*] for example, there it allows to sync
> backing chains during query block stats.
> 
> In discussion of [1] I stated that first patch will also allow to get rid of
> stale block job events on reconnection to qemu. But this will require
> additional work actually so with this patch series stale events are still
> present. And in the discussion it was also mentioned by Peter that stale events
> are not harmful for legacy blockjobs code. I also removed previous attempts to
> eliminate some of stale events.
> 
> I still keep patch for virDomainGetBlockJobInfo. May be in comparsion to [*]
> the approach the patch takes will look not so bad :)
> 
> [1] First version of the patch series
> https://www.redhat.com/archives/libvir-list/2020-October/msg01133.html

I had a look at this series and it's just doing too much just to "fix"
apps which insist on polling especially with pre-blockdev qemu. I simply
it's not worth adding the complexity you are proposing.

NACK series.

Instead I propose we add a workaround which will report fake unfinished
job:

https://www.redhat.com/archives/libvir-list/2020-December/msg00352.html

The scope of this is way more limited and it doesn't actually try to
modify the job code handovers which is very dangerous.



I had a look at this series and it's just doing too much just to "fix"
apps which insist on polling especially with pre-blockdev qemu.

Additionally it adds documentation stating that apps should not poll
virDomainGetBlockJobInfo.




More information about the libvir-list mailing list