xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH RFC 1/3] x86/vpt: execute callbacks for masked interrupts
Date: Mon, 26 Feb 2018 12:48:24 +0000	[thread overview]
Message-ID: <20180226124810.77uqvmdm7nodm32f@MacBook-Pro-de-Roger.local> (raw)
In-Reply-To: <20180226123554.ep76zgkatb2zswv4@citrix.com>

On Mon, Feb 26, 2018 at 12:35:54PM +0000, Wei Liu wrote:
> On Fri, Feb 23, 2018 at 01:27:41PM +0000, Roger Pau Monne wrote:
> > Execute periodic_time callbacks even if the interrupt is not actually
> > injected because the IRQ is masked.
> > 
> > Current callbacks from emulated timer devices only update emulated
> > registers, which from my reading of the specs should happen regardless
> > of whether the interrupt has been injected or not.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Cc: Jan Beulich <jbeulich@suse.com>
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: Stefan Bader <stefan.bader@canonical.com>
> > ---
> >  xen/arch/x86/hvm/vpt.c | 30 +++++++++++++++++++++++++++++-
> >  1 file changed, 29 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
> > index 181f4cb631..1a24fbaa44 100644
> > --- a/xen/arch/x86/hvm/vpt.c
> > +++ b/xen/arch/x86/hvm/vpt.c
> > @@ -247,9 +247,31 @@ static void pt_timer_fn(void *data)
> >      pt_unlock(pt);
> >  }
> >  
> > +static void execute_callbacks(struct vcpu *v, struct list_head *tm)
> > +{
> > +    spin_lock(&v->arch.hvm_vcpu.tm_lock);
> > +    while ( !list_empty(tm) )
> > +    {
> > +        struct periodic_time *pt = list_first_entry(tm, struct periodic_time,
> > +                                                    list);
> > +        time_cb *cb = pt->cb;
> > +        void *cb_priv = pt->priv;
> > +
> > +        list_del(&pt->list);
> > +        pt->on_list = 0;
> > +        spin_unlock(&v->arch.hvm_vcpu.tm_lock);
> > +
> > +        cb(v, cb_priv);
> > +
> > +        spin_lock(&v->arch.hvm_vcpu.tm_lock);
> > +    }
> > +    spin_unlock(&v->arch.hvm_vcpu.tm_lock);
> > +}
> > +
> >  int pt_update_irq(struct vcpu *v)
> >  {
> >      struct list_head *head = &v->arch.hvm_vcpu.tm_list;
> > +    LIST_HEAD(purged);
> 
> to_purge?

My point is that they have already been purged from the pt->list, but
I really don't have a preference.

> >      struct periodic_time *pt, *temp, *earliest_pt;
> >      uint64_t max_lag;
> >      int irq, is_lapic, pt_vector;
> > @@ -267,7 +289,10 @@ int pt_update_irq(struct vcpu *v)
> >              {
> >                  /* suspend timer emulation */
> >                  list_del(&pt->list);
> > -                pt->on_list = 0;
> > +                if ( pt->cb )
> > +                    list_add(&pt->list, &purged);
> > +                else
> > +                    pt->on_list = 0;
> >              }
> >              else
> >              {
> > @@ -283,6 +308,7 @@ int pt_update_irq(struct vcpu *v)
> >      if ( earliest_pt == NULL )
> >      {
> >          spin_unlock(&v->arch.hvm_vcpu.tm_lock);
> > +        execute_callbacks(v, &purged);
> 
> It would be better to check if the list is not empty before calling the
> function to avoid the extra lock / unlock.

The lock is also protecting the 'purged' list, so I think that for
consistency the lock needs to be held before accessing it.

Since this is only a empty check *and* there can't be any
additions to the list at this point I guess it would be safe to test
for emptiness without holding the lock, but I find it kind of
confusing.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-02-26 12:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-23 13:27 [PATCH RFC 0/3] hpet: add support for level triggered interrupts Roger Pau Monne
2018-02-23 13:27 ` [PATCH RFC 1/3] x86/vpt: execute callbacks for masked interrupts Roger Pau Monne
2018-02-26 12:35   ` Wei Liu
2018-02-26 12:48     ` Roger Pau Monné [this message]
2018-02-26 13:04       ` Jan Beulich
2018-02-26 14:12         ` Roger Pau Monné
2018-02-23 13:27 ` [PATCH RFC 2/3] vhpet: add support for level triggered interrupts Roger Pau Monne
2018-02-23 13:27 ` [PATCH RFC 3/3] xtf: add minimal HPET functionality test Roger Pau Monne
2018-02-23 19:07   ` Wei Liu
2018-02-28 15:37     ` Roger Pau Monné
2018-02-28 16:24       ` Jan Beulich
2018-03-01  9:55         ` Roger Pau Monné
2018-03-01 10:04           ` Jan Beulich
2018-03-01 10:14             ` Roger Pau Monné
2018-03-01 10:22               ` Jan Beulich
2018-03-01 11:46   ` Andrew Cooper
2018-03-01 12:57     ` 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=20180226124810.77uqvmdm7nodm32f@MacBook-Pro-de-Roger.local \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=stefan.bader@canonical.com \
    --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).