xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com
Subject: Re: [PATCH-4.5 3/4] xen/arm: do not request maintenance_interrupts
Date: Mon, 10 Feb 2014 17:11:04 +0000	[thread overview]
Message-ID: <52F90828.4060809@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1402101705340.4373@kaball.uk.xensource.com>

On 02/10/2014 05:06 PM, Stefano Stabellini wrote:
> On Fri, 7 Feb 2014, Julien Grall wrote:
>> On 07/02/14 18:56, Stefano Stabellini wrote:
>>    > +static void gic_clear_lrs(struct vcpu *v)
>>> +{
>>> +    struct pending_irq *p;
>>> +    int i = 0, irq;
>>> +    uint32_t lr;
>>> +    bool_t inflight;
>>> +
>>> +    ASSERT(!local_irq_is_enabled());
>>> +
>>> +    while ((i = find_next_bit((const long unsigned int *)
>>> &this_cpu(lr_mask),
>>> +                              nr_lrs, i)) < nr_lrs) {
>>
>> Did you look at to ELRSR{0,1} registers which list the usable LRs? I think you
>> can use it with the this_cpu(lr_mask) to avoid browsing every LRs.
> 
> Given that we only have 4 LR registers, I think that unconditionally
> reading 2 ELRSR registers would cost more than simply checking lr_mask
> on average.

The maximum number of LR registers is 64. I agree that the current
hardwares only handle 4 ... but we should think about future hardware.

-- 
Julien Grall

  parent reply	other threads:[~2014-02-10 17:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07 18:56 [PATCH-4.5 0/4] remove maintenance interrupts Stefano Stabellini
2014-02-07 18:56 ` [PATCH-4.5 1/4] xen/arm: remove unused virtual parameter from vgic_vcpu_inject_irq Stefano Stabellini
2014-02-07 22:06   ` Julien Grall
2014-02-07 18:56 ` [PATCH-4.5 2/4] xen/arm: support HW interrupts in gic_set_lr Stefano Stabellini
2014-02-07 22:31   ` Julien Grall
2014-02-10 16:50     ` Stefano Stabellini
2014-02-07 18:56 ` [PATCH-4.5 3/4] xen/arm: do not request maintenance_interrupts Stefano Stabellini
2014-02-07 22:45   ` Julien Grall
2014-02-10 17:03     ` Stefano Stabellini
2014-02-10 17:21       ` Julien Grall
2014-02-07 23:10   ` Julien Grall
2014-02-10 17:06     ` Stefano Stabellini
2014-02-10 17:09       ` Ian Campbell
2014-02-10 17:16         ` Stefano Stabellini
2014-02-10 17:18           ` Ian Campbell
2014-02-10 17:24             ` Stefano Stabellini
2014-02-10 17:33               ` Ian Campbell
2014-02-10 17:11       ` Julien Grall [this message]
2014-02-07 18:56 ` [PATCH-4.5 4/4] xen/arm: set GICH_HCR_NPIE if all the LRs are in use Stefano Stabellini
2014-02-07 23:39   ` Julien Grall
2014-02-10 16:59     ` Stefano Stabellini
2014-02-10 17:14       ` Julien Grall
2014-02-10 17:16         ` Stefano Stabellini
2014-02-07 23:22 ` [PATCH-4.5 0/4] remove maintenance interrupts Julien Grall
2014-02-10 17:08   ` Stefano Stabellini

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=52F90828.4060809@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --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 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).