On Thu, Aug 22, 2019 at 11:15:50AM +0200, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monne <[email protected]> > > Sent: 21 August 2019 15:59 > > To: [email protected] > > Cc: Roger Pau Monne <[email protected]>; Paul Durrant > > <[email protected]>; Jan Beulich > > <[email protected]>; Andrew Cooper <[email protected]>; Wei Liu > > <[email protected]>; George Dunlap > > <[email protected]>; Ian Jackson <[email protected]>; Julien > > Grall <[email protected]>; > > Konrad Rzeszutek Wilk <[email protected]>; Stefano Stabellini > > <[email protected]>; Tim > > (Xen.org) <[email protected]> > > Subject: [PATCH 7/7] ioreq: provide support for long-running operations... > > > > ...and switch vPCI to use this infrastructure for long running > > physmap modification operations. > > > > This allows to get rid of the vPCI specific modifications done to > > handle_hvm_io_completion and allows generalizing the support for > > long-running operations to other internal ioreq servers. Such support > > is implemented as a specific handler that can be registers by internal > > ioreq servers and that will be called to check for pending work. > > Returning true from this handler will prevent the vcpu from running > > until the handler returns false. > > Rather than having another callback can the handler not be re-called with > same ioreq? It could return different values depending on whether there is > more work to do (requiring another call) or whether it is done and the vcpu > can be resumed. Would that work?
I guess this would work also. The issue with this approach is that I would have to find somewhere to store the ioreq while the operation is being processed, which is not required with the proposed two handler approach. Thanks, Roger. _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
