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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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