>>> On 13.11.14 at 16:46, <t...@xen.org> wrote: > That leaves paging_log_dirty_op(). The inner loops of that function > are already set up to be preempted for softirqs, &c. I wonder could > we arrange for it to map the first N pages of bitmap before taking any > locks, and then drop the locks after that many pages, and unmap them > again. > > It wouldn't even need to actually set up a hypercall continuation if > !hypercall_preempt_check(); it can simply map a new batch and carry > on. > > Does that sounds plausible? If so, then we can leave the lock > constraints as they are, which would make me very happy. :)
Apart from the already not too easily readable code becoming even more convoluted, one possible extra problem I see is that d->arch.paging.preempt modifications are currently being protected by the paging lock. I.e. acquiring that lock later and dropping it intermediately would further complicate the state tracking here. But maybe this could be dealt with by setting d->arch.paging.preempt.dom to current->domain earlier (i.e. before even starting)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
