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

Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom.



On Fri, 2012-06-29 at 11:37 +0100, Keir Fraser wrote:
> On 29/06/2012 11:14, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> >> Agree on moving it out of the loop. But why would you want it protected by
> >> iorp->lock?
> > 
> > I suggested it because the user of the field locks with that lock.
> 
> That lock is really protecting access to the shared bufioreq page. The
> evtchn notify could equally well be moved outside the lock.

OK.

> > I think that even with the xchg there is still scope for the old event
> > channel to be in use in hvm_buffered_io_send after it has been replaced.
> > The xchg just protects against concurrent freeing.
> 
> A. This would be equally true for the per-vcpu hvm_vcpu.xen_port; but
> B. We avoid such races by domain_pause()ing when changing
> HVM_PARAM_DM_DOMAIN; and
> C. In practice we only set HVM_PARAM_DM_DOMAIN before the guest starts to
> run anyway.

I thought we locked the update of xen_port too -- but actually that's
only the update of get_ioreq(v)->vp_eport, which is locked against
iorp->va changing.

Ian.



_______________________________________________
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®.