xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

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