From: Keir Fraser <keir.xen@gmail.com>
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>
Subject: Re: [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom.
Date: Fri, 29 Jun 2012 11:37:56 +0100 [thread overview]
Message-ID: <CC134414.3728C%keir.xen@gmail.com> (raw)
In-Reply-To: <1340964863.10942.89.camel@zakaz.uk.xensource.com>
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
next prev parent reply other threads:[~2012-06-29 10:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 15:21 [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom Anthony PERARD
2012-06-29 8:26 ` Ian Campbell
2012-06-29 10:12 ` Keir Fraser
2012-06-29 8:50 ` Jan Beulich
2012-06-29 10:10 ` Keir Fraser
2012-06-29 10:14 ` Ian Campbell
2012-06-29 10:37 ` Keir Fraser [this message]
2012-06-29 10:45 ` Ian Campbell
2012-06-29 10:25 ` Jan Beulich
2012-06-29 11:04 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CC134414.3728C%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=anthony.perard@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).