From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Keir Fraser <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH 2/8] evtchn: refactor low-level event channel port ops
Date: Fri, 6 Sep 2013 15:25:19 +0100 [thread overview]
Message-ID: <5229E5CF.8000005@citrix.com> (raw)
In-Reply-To: <520CFC5B02000078000EC402@nat28.tlf.novell.com>
On 15/08/13 15:05, Jan Beulich wrote:
>>>> On 09.08.13 at 20:08, David Vrabel <david.vrabel@citrix.com> wrote:
>> +static void evtchn_2l_set_pending(struct vcpu *v, struct evtchn *evtchn)
>> +{
>> + struct domain *d = v->domain;
>> + unsigned port = evtchn->port;
>> +
>> + /*
>> + * The following bit operations must happen in strict order.
>> + * NB. On x86, the atomic bit operations also act as memory barriers.
>> + * There is therefore sufficiently strict ordering for this architecture --
>> + * others may require explicit memory barriers.
>> + */
>> +
>> + if ( test_and_set_bit(port, &shared_info(d, evtchn_pending)) )
>> + return;
>> +
>> + if ( !test_bit (port, &shared_info(d, evtchn_mask)) &&
>> + !test_and_set_bit(port / BITS_PER_EVTCHN_WORD(d),
>> + &vcpu_info(v, evtchn_pending_sel)) )
>
> Up to here this is indeed 2-level specific, but the rest of the
> function isn't, and would therefore better go back into
> generic code.
I think it is fine for the ABI specific hooks to make calls to common
code but tried this anyway and I don't think it's an improvement.
The set_pending has to return three different states:
1. Do nothing.
2. Mark vcpu pending
3. Mark vcpu pending and check pollers.
I tried a couple of ways of doing this but they all look ugly with extra
branches with an interface that's less clear.
e.g.,
static bool_t evtchn_2l_set_pending(struct vcpu *v,
struct evtchn *evtchn)
{
struct domain *d = v->domain;
unsigned port = evtchn->port;
unsigned action = 0;
if ( test_and_set_bit(port, &shared_info(d, evtchn_pending)) )
return action;
if ( !test_bit (port, &shared_info(d, evtchn_mask)) &&
!test_and_set_bit(port / BITS_PER_EVTCHN_WORD(d),
&vcpu_info(v, evtchn_pending_sel)) )
{
action |= MARK_PENDING;
}
action |= CHECK_POLLERS
return action;
}
[...]
static void evtchn_set_pending(struct vcpu *v, int port)
{
struct domain *d = v->domain;
unsigned action;
action = evtchn_port_set_pending(v, evtchn_from_port(d, port));
if ( action & MARK_PENDING )
vcpu_mark_pending(v);
if ( action & CHECK_PENDING )
evtchn_check_pollers(d, port);
}
Which just looks bleah to me.
I also tried:
static bool_t evtchn_2l_set_pending(struct vcpu *v,
struct evtchn *evtchn)
{
struct domain *d = v->domain;
unsigned port = evtchn->port;
if ( test_and_set_bit(port, &shared_info(d, evtchn_pending)) )
return 0;
if ( !test_bit (port, &shared_info(d, evtchn_mask)) &&
!test_and_set_bit(port / BITS_PER_EVTCHN_WORD(d),
&vcpu_info(v, evtchn_pending_sel)) )
{
vcpu_mark_events_pending(v);
}
return 1;
}
[...]
static void evtchn_set_pending(struct vcpu *v, int port)
{
struct domain *d = v->domain;
if (evtchn_port_set_pending(v, evtchn_from_port(d, port)))
evtchn_check_pollers(d, port);
}
But this means we can't move the vcpu_mark_events_pending() out of the
unmask hook because the FIFO unmask calls set_pending which calls
vcpu_mark_events_pending().
Any other suggestions or is the original fine as-is?
David
next prev parent reply other threads:[~2013-09-06 14:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 18:08 [RFC PATCH 0/8] Xen: FIFO-based event channel ABI David Vrabel
2013-08-09 18:08 ` [PATCH 1/8] debug: remove some event channel info from the 'i' and 'q' debug keys David Vrabel
2013-08-15 13:55 ` Jan Beulich
2013-08-09 18:08 ` [PATCH 2/8] evtchn: refactor low-level event channel port ops David Vrabel
2013-08-15 14:05 ` Jan Beulich
2013-09-06 14:25 ` David Vrabel [this message]
2013-09-06 14:55 ` Jan Beulich
2013-08-09 18:08 ` [PATCH 3/8] evtchn: add a hook to bind an event port to a VCPU David Vrabel
2013-08-09 18:08 ` [PATCH 4/8] evtchn: use a per-domain variable for the max number of event channels David Vrabel
2013-08-15 14:09 ` Jan Beulich
2013-08-09 18:08 ` [PATCH 5/8] evtchn: dynamically allocate d->evtchn David Vrabel
2013-08-15 14:10 ` Jan Beulich
2013-08-09 18:08 ` [PATCH 6/8] evtchn: alter internal object handling scheme David Vrabel
2013-08-15 14:21 ` Jan Beulich
2013-08-15 15:46 ` David Vrabel
2013-08-16 7:14 ` Jan Beulich
2013-08-16 16:55 ` Wei Liu
2013-08-09 18:08 ` [PATCH 7/8] evtchn: add FIFO-based event channel ABI David Vrabel
2013-08-15 14:25 ` Jan Beulich
2013-08-09 18:08 ` [PATCH 8/8] evtchn: add FIFO-based event channel hypercalls and port ops David Vrabel
2013-08-16 16:33 ` Wei Liu
2013-08-19 10:32 ` David Vrabel
2013-08-19 10:46 ` Wei Liu
2013-08-23 10:33 ` Jan Beulich
2013-08-23 11:00 ` David Vrabel
2013-08-12 13:06 ` [RFC PATCH 0/8] Xen: FIFO-based event channel ABI George Dunlap
2013-08-12 13:49 ` David Vrabel
2013-08-16 16:55 ` Wei Liu
-- strict thread matches above, loose matches on Subject: below --
2013-03-19 21:00 [PATCH RFC " David Vrabel
2013-03-19 21:00 ` [PATCH 2/8] evtchn: refactor low-level event channel port ops David Vrabel
2013-03-20 10:21 ` Jan Beulich
2013-03-20 13:37 ` David Vrabel
2013-03-20 10:24 ` Jan Beulich
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=5229E5CF.8000005@citrix.com \
--to=david.vrabel@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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).