From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Julien Grall <julien.grall@citrix.com>, Chen Baozi <baozich@gmail.com>
Cc: xen-devel@lists.xenproject.org, Chen Baozi <cbz@baozis.org>,
Campbell Ian <ian.campbell@citrix.com>
Subject: Re: [PATCH V5 09/10] xen/arm: make domain_max_vcpus return value from vgic_ops
Date: Sun, 31 May 2015 19:21:19 +0100 [thread overview]
Message-ID: <556B511F.8060400@citrix.com> (raw)
In-Reply-To: <556B4D5D.6000503@citrix.com>
On 31/05/15 19:05, Julien Grall wrote:
> Hi Chen,
>
> On 31/05/2015 16:31, Chen Baozi wrote:
>>> On May 31, 2015, at 21:35, Julien Grall <julien.grall@citrix.com>
>>> wrote:
>>>> +
>>>> #define NR_GIC_LOCAL_IRQS NR_LOCAL_IRQS
>>>> #define NR_GIC_SGI 16
>>>> #define MAX_RDIST_COUNT 4
>>>> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>>>> index 2f413e1..1157b04 100644
>>>> --- a/xen/include/asm-arm/vgic.h
>>>> +++ b/xen/include/asm-arm/vgic.h
>>>> @@ -110,6 +110,8 @@ struct vgic_ops {
>>>> struct vcpu *(*get_target_vcpu)(struct vcpu *v, unsigned int
>>>> irq);
>>>> /* vGIC sysreg emulation */
>>>> int (*emulate_sysreg)(struct cpu_user_regs *regs, union hsr
>>>> hsr);
>>>> + /* Get the maximum number of vCPU supported */
>>>> + int (*get_max_vcpus)(void);
>>>
>>> Why did you create a function? The value never change so a field
>>> value would have been better…
>>
>> But is it appropriate that we define a field value in a struct called
>> vgic_ops? I
>> thought ‘XXX_ops’ refers to a struct that is made up by function
>> points. (FIXME)
>
> Well if the only issue if the name, please rename the structure. IHMO,
> the name is fine for me, I will let Ian & Stefano decides about it.
>
> As the vGIC is always supporting N cpus and will never change, it's
> pointless to use a function (thinking about the "cost" vs access an
> field).
We have plenty of other structures with mixed function pointers and data.
A "const unsigned int max_vcpus;" should absolutely be used in a case
like this.
~Andrew
next prev parent reply other threads:[~2015-05-31 18:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-30 11:07 [PATCH V5 00/10] Support more than 8 vcpus on arm64 with GICv3 Chen Baozi
2015-05-30 11:07 ` [PATCH V5 01/10] xen/arm: gic-v3: Increase the size of GICR in address space for guest Chen Baozi
2015-05-30 11:07 ` [PATCH V5 02/10] xen/arm: Add functions of mapping between vCPUID and virtual affinity Chen Baozi
2015-05-31 12:51 ` Julien Grall
2015-05-30 11:07 ` [PATCH V5 03/10] xen/arm: Use the new functions for vCPUID/vaffinity transformation Chen Baozi
2015-05-31 12:53 ` Julien Grall
2015-05-30 11:07 ` [PATCH V5 04/10] xen/arm: Use cpumask_t type for vcpu_mask in vgic_to_sgi Chen Baozi
2015-05-31 13:05 ` Julien Grall
2015-05-30 11:07 ` [PATCH V5 05/10] xen/arm64: gicv3: Use AFF1 when translating ICC_SGI1R_EL1 to cpumask Chen Baozi
2015-05-30 11:15 ` Chen Baozi
2015-05-31 13:14 ` Julien Grall
2015-05-31 15:25 ` Chen Baozi
2015-05-31 17:58 ` Julien Grall
2015-05-30 11:07 ` [PATCH V5 06/10] tools/libxl: Set 'reg' of cpu node equal to MPIDR affinity for domU Chen Baozi
2015-05-31 13:16 ` Julien Grall
2015-05-30 11:07 ` [PATCH V5 07/10] xen/arm: Set 'reg' of cpu node for dom0 to match MPIDR's affinity Chen Baozi
2015-05-31 13:20 ` Julien Grall
2015-05-30 11:07 ` [PATCH V5 08/10] xen: Call arch_domain_create() before evtchn_init() Chen Baozi
2015-05-31 13:29 ` Julien Grall
2015-05-30 11:07 ` [PATCH V5 09/10] xen/arm: make domain_max_vcpus return value from vgic_ops Chen Baozi
2015-05-31 13:35 ` Julien Grall
2015-05-31 15:31 ` Chen Baozi
2015-05-31 18:05 ` Julien Grall
2015-05-31 18:21 ` Andrew Cooper [this message]
2015-05-30 11:07 ` [PATCH V5 10/10] xen/arm64: increase MAX_VIRT_CPUS to 128 on arm64 Chen Baozi
2015-05-31 13:40 ` Julien Grall
2015-05-31 15:37 ` Chen Baozi
2015-05-31 18:21 ` Julien Grall
2015-06-01 0:56 ` Chen Baozi
2015-06-01 8:04 ` 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=556B511F.8060400@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=baozich@gmail.com \
--cc=cbz@baozis.org \
--cc=ian.campbell@citrix.com \
--cc=julien.grall@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.