[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 1/3] x86/vpt: execute callbacks for masked interrupts



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@xxxxxxxxxx>
> > ---
> > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > Cc: Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
> > ---
> >  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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.