[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 1/2] xen/pvh: take the p2m lock when doing logdirty ops from HVM domains



>>> On 13.11.14 at 16:46, <tim@xxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.