From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
Date: Fri, 29 Jun 2012 11:37:56 +0100
Message-ID: <CC134414.3728C%keir.xen@gmail.com>
References: <1340964863.10942.89.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1340964863.10942.89.camel@zakaz.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 29/06/2012 11:14, "Ian Campbell" <Ian.Campbell@citrix.com> 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