All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>, Chen Baozi <cbz@baozis.org>
Cc: xen-devel@lists.xenproject.org, Chen Baozi <baozich@gmail.com>
Subject: Re: [PATCH v8 4/8] xen/arm: Use AFF1 when translating ICC_SGI1R_EL1 to cpumask
Date: Wed, 17 Jun 2015 14:13:28 +0100	[thread overview]
Message-ID: <55817278.7050409@citrix.com> (raw)
In-Reply-To: <1434546030.13744.369.camel@citrix.com>

On 17/06/15 14:00, Ian Campbell wrote:
> On Fri, 2015-06-12 at 16:32 +0800, Chen Baozi wrote:
>> From: Chen Baozi <baozich@gmail.com>
>>
>> The old unsigned long type of vcpu_mask can only express 64 cpus at the
>> most, which might not be enough for the guest which used vGICv3. We
>> introduce a new struct sgi_target for the target cpu list of SGI, which
>> holds the affinity path information (only level 1 at the moment). For
>> GICv2 that has no affinity level, we can just set the corresponding
>> fields to be 0.
>>
>> Signed-off-by: Chen Baozi <baozich@gmail.com>
>> ---
>>  xen/arch/arm/vgic-v2.c            |  7 +++---
>>  xen/arch/arm/vgic-v3.c            | 10 +++++----
>>  xen/arch/arm/vgic.c               | 45 +++++++++++++++++----------------------
>>  xen/include/asm-arm/gic_v3_defs.h |  3 +++
>>  xen/include/asm-arm/vgic.h        |  7 +++++-
>>  5 files changed, 38 insertions(+), 34 deletions(-)
>>
>> diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
>> index 3be1a51..5949cf1 100644
>> --- a/xen/arch/arm/vgic-v2.c
>> +++ b/xen/arch/arm/vgic-v2.c
>> @@ -201,16 +201,17 @@ static int vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
>>      int virq;
>>      int irqmode;
>>      enum gic_sgi_mode sgi_mode;
>> -    unsigned long vcpu_mask = 0;
>> +    struct sgi_target target;
>>  
>> +    memset(&target, 0, sizeof(struct sgi_target));
> 
> I'd prefer explicit initialisation of the relevant fields please. Which
> may mean setting aff1 to 0 somewhere at the top, with a suitable comment
> as to why, and might involve setting target.list to zero in some other
> cases below or via an explicit initialiser here.

Well, only SGI_TARGET_LIST is caring about struct sgi_target (see
vgic_to_sgi). I would only initialize it when it's required.

> Or maybe you prefer a struct initialiser on the declaration with the
> defaults.

It would be nice to have something initializing all the fields (even a
new one is added). It would avoid problem later.

>> -    unsigned long vcpu_mask = 0;
>> +    struct sgi_target target;
>>  
>> +    memset(&target, 0, sizeof(struct sgi_target));
> 
> Likewise.
> 
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 7b387b7..59bd98a 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -318,15 +318,14 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>>      }
>>  }
>>  
>> -/* TODO: unsigned long is used to fit vcpu_mask.*/
>>  int vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, int virq,
>> -                unsigned long vcpu_mask)
>> +                const struct sgi_target *target)
> 
> For a 3 byte struct perhaps we can pass by value instead of reference?
> 
> I suppose it might eventually be 5 bytes, but even so...
> 
>> @@ -334,29 +333,33 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, int
>>      {
>>      case SGI_TARGET_LIST:
>>          perfc_incr(vgic_sgi_list);
>> +        base = target->aff1 << 4;
>> +        bitmap = target->list;
>> +        for_each_set_bit( i, &bitmap, sizeof(target->list) * 8 )
>> +        {
>> +            vcpuid = base + i;
>> +            if ( d->vcpu[vcpuid] != NULL && !is_vcpu_online(d->vcpu[vcpuid]) )
> 
> What if d->vcpu[vcpuid] is NULL? (Was this a latent bug before, or am I
> missing something?)

I don't see any problem, if d->vcpu[vcpuid] is NULL there is no need to
send an SGI as the VCPU is not present.

Although d->vcpu[vcpuid] will unlikely be NULL.

> Note that at least the use of d->max_vcpus from the old code has now
> gone.

The array d->vcpu is based on d->max_vcpus, if by any chance vcpuid is
greater, you will access to a wrong address which will potentially crash
the host.

Regards,

-- 
Julien Grall

  reply	other threads:[~2015-06-17 13:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12  8:32 [PATCH v8 0/8] Support more than 8 vcpus on arm64 with GICv3 Chen Baozi
2015-06-12  8:32 ` [PATCH v8 1/8] xen/arm: gic-v3: Increase the size of GICR in address space for guest Chen Baozi
2015-06-12  8:32 ` [PATCH v8 2/8] xen/arm: Add functions of mapping between vCPUID and virtual affinity Chen Baozi
2015-06-17 12:48   ` Ian Campbell
2015-06-12  8:32 ` [PATCH v8 3/8] xen/arm: Use the new functions for vCPUID/vaffinity transformation Chen Baozi
2015-06-17 12:50   ` Ian Campbell
2015-06-12  8:32 ` [PATCH v8 4/8] xen/arm: Use AFF1 when translating ICC_SGI1R_EL1 to cpumask Chen Baozi
2015-06-17 13:00   ` Ian Campbell
2015-06-17 13:13     ` Julien Grall [this message]
2015-06-17 13:19       ` Ian Campbell
2015-06-17 13:32         ` Julien Grall
2015-06-12  8:32 ` [PATCH v8 5/8] tools/libxl: Set 'reg' of cpu node equal to MPIDR affinity for domU Chen Baozi
2015-06-12  8:32 ` [PATCH v8 6/8] xen/arm: Set 'reg' of cpu node for dom0 to match MPIDR's affinity Chen Baozi
2015-06-12  8:32 ` [PATCH v8 7/8] xen/arm: make domain_max_vcpus return value from vgic_ops Chen Baozi
2015-06-17 13:02   ` Ian Campbell
2015-06-12  8:32 ` [PATCH v8 8/8] xen/arm64: increase MAX_VIRT_CPUS to 128 on arm64 Chen Baozi
2015-06-17 13:03   ` Ian Campbell
2015-06-17 13:04 ` [PATCH v8 0/8] Support more than 8 vcpus on arm64 with GICv3 Ian Campbell
2015-06-17 13:45   ` Julien Grall

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=55817278.7050409@citrix.com \
    --to=julien.grall@citrix.com \
    --cc=baozich@gmail.com \
    --cc=cbz@baozis.org \
    --cc=ian.campbell@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 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.