All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim (Xen.org)" <tim@xen.org>
Subject: Re: [PATCH 7/7] xen/arm: phys_timer fixes
Date: Mon, 18 Feb 2013 15:01:29 +0000	[thread overview]
Message-ID: <1361199689.32047.28.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>

On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > >  {
> > >      struct vtimer *t = data;
> > >      t->ctl |= CNTx_CTL_PENDING;
> > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > 
> > Thinking about the previous discussion about exposing the change of the
> > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > actually represent the state of the underlying physical mask bit, since
> > we do emulate accesses after all.
> 
> Sure. However this change still makes sense: if the guest masked the
> timer (no matter how we internally represent it), we should not inject
> an interrupt.

Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
also, it should be set only when the guest masks the interrupt.


> 
> 
> > >  }
> > >  
> > >  static void virt_timer_expired(void *data)
> > > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> > >      vgic_vcpu_inject_irq(t->v, 27, 1);
> > >  }
> > >   
> > > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > > +{
> > > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > > +}
> > > +
> > > +int __init init_ptimer(void)
> > > +{
> > > +    register_gic_callback(30, phys_timer_gic_callback);
> > > +    return 0;
> > > +}
> > > +
> > >  int vcpu_vtimer_init(struct vcpu *v)
> > >  {
> > >      struct vtimer *t = &v->arch.phys_timer;
> > > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > >          {
> > >              v->arch.phys_timer.ctl = *r;
> > >  
> > > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> > 
> > Why does PENDING matter here and below?
> 
> Doing tests on the physical hardware to better understand its behaviour,
> I noticed that the pending bit gets set even if the timer is masked
> (and therefore no interrupt is asserted).

The manual says that the pending bit (which the newer docs call
"istatus") is the interrupt status before masking, so this statement
doesn't really make sense in that context because "even if the timer is
masked" doesn't really mean anything given that, since this bit is only
really useful when the interrupt is masked.

if there are discrepancies between the hardware and the documentation
(which is on the confusing side in this case, although the newest doc is
better) it would probably be better to get ARM to clarify than to guess
what the behaviour is suppose to be.

> However if the pending bit is already set there is no point for us to
> try to set it again, so we skip setting the internal Xen timer.

I have a feeling this is only true because we incorrectly set the
pending bit in phys_timer_expired().

Ian.

  reply	other threads:[~2013-02-18 15:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-14 16:37 [PATCH 7/7] xen/arm: phys_timer fixes Stefano Stabellini
2013-02-15 13:04 ` Ian Campbell
2013-02-18 14:44   ` Stefano Stabellini
2013-02-18 15:01     ` Ian Campbell [this message]
2013-02-18 15:31       ` Stefano Stabellini
2013-02-18 15:54         ` Ian Campbell
2013-02-18 16:14           ` Stefano Stabellini
2013-02-18 16:23             ` Ian Campbell

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=1361199689.32047.28.camel@zakaz.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.