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

[Keir Fraser <keir.xen@xxxxxxxxx>]

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.

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

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel