From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <yuzenghui@huawei.com>, <kvmarm@lists.cs.columbia.edu>,
<linux-kernel@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jason Cooper <jason@lakedaemon.net>
Subject: Re: [PATCH 10/35] irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER) allocation
Date: Wed, 25 Sep 2019 18:14:46 +0100 [thread overview]
Message-ID: <e64126d2adf7ea5fe5c75bd4bcdce6e0@www.loen.fr> (raw)
In-Reply-To: <6f4ccdfd-4b63-04cb-e7c0-f069e620127f@kernel.org>
On 2019-09-25 15:41, Marc Zyngier wrote:
> On 25/09/2019 14:04, Zenghui Yu wrote:
>> Hi Marc,
>>
>> Some questions about this patch, mostly to confirm that I would
>> understand things here correctly.
>>
>> On 2019/9/24 2:25, Marc Zyngier wrote:
>>> GICv4.1 defines a new VPE table that is potentially shared between
>>> both the ITSs and the redistributors, following complicated
>>> affinity
>>> rules.
>>>
>>> To make things more confusing, the programming of this table at
>>> the redistributor level is reusing the GICv4.0 GICR_VPROPBASER
>>> register
>>> for something completely different.
>>>
>>> The code flow is somewhat complexified by the need to respect the
>>> affinities required by the HW, meaning that tables can either be
>>> inherited from a previously discovered ITS or redistributor.
>>>
>>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>>> ---
>>
>> [...]
>>
>>> @@ -1962,6 +1965,65 @@ static bool its_parse_indirect_baser(struct
>>> its_node *its,
>>> return indirect;
>>> }
>>>
>>> +static u32 compute_common_aff(u64 val)
>>> +{
>>> + u32 aff, clpiaff;
>>> +
>>> + aff = FIELD_GET(GICR_TYPER_AFFINITY, val);
>>> + clpiaff = FIELD_GET(GICR_TYPER_COMMON_LPI_AFF, val);
>>> +
>>> + return aff & ~(GENMASK(31, 0) >> (clpiaff * 8));
>>> +}
>>> +
>>> +static u32 compute_its_aff(struct its_node *its)
>>> +{
>>> + u64 val;
>>> + u32 svpet;
>>> +
>>> + /*
>>> + * Reencode the ITS SVPET and MPIDR as a GICR_TYPER, and compute
>>> + * the resulting affinity. We then use that to see if this match
>>> + * our own affinity.
>>> + */
>>> + svpet = FIELD_GET(GITS_TYPER_SVPET, its->typer);
>>> + val = FIELD_PREP(GICR_TYPER_COMMON_LPI_AFF, svpet);
>>> + val |= FIELD_PREP(GICR_TYPER_AFFINITY, its->mpidr);
>>> + return compute_common_aff(val);
>>> +}
>>> +
>>> +static struct its_node *find_sibbling_its(struct its_node
>>> *cur_its)
>>> +{
>>> + struct its_node *its;
>>> + u32 aff;
>>> +
>>> + if (!FIELD_GET(GITS_TYPER_SVPET, cur_its->typer))
>>> + return NULL;
>>> +
>>> + aff = compute_its_aff(cur_its);
>>> +
>>> + list_for_each_entry(its, &its_nodes, entry) {
>>> + u64 baser;
>>> +
>>> + if (!is_v4_1(its) || its == cur_its)
>>> + continue;
>>> +
>>> + if (!FIELD_GET(GITS_TYPER_SVPET, its->typer))
>>> + continue;
>>> +
>>> + if (aff != compute_its_aff(its))
>>> + continue;
>>> +
>>> + /* GICv4.1 guarantees that the vPE table is GITS_BASER2 */
>>> + baser = its->tables[2].val;
>>> + if (!(baser & GITS_BASER_VALID))
>>> + continue;
>>> +
>>> + return its;
>>> + }
>>> +
>>> + return NULL;
>>> +}
>>> +
>>> static void its_free_tables(struct its_node *its)
>>> {
>>> int i;
>>> @@ -2004,6 +2066,15 @@ static int its_alloc_tables(struct its_node
>>> *its)
>>> break;
>>>
>>> case GITS_BASER_TYPE_VCPU:
>>> + if (is_v4_1(its)) {
>>> + struct its_node *sibbling;
>>> +
>>> + if ((sibbling = find_sibbling_its(its))) {
>>> + its->tables[2] = sibbling->tables[2];
>>
>> This means thst the vPE table is shared between ITSs which are under
>> the
>> same affinity group?
>
> That's indeed what this is trying to do...
>
>> Don't we need to set GITS_BASER (by its_setup_baser()) here to tell
>> this
>> ITS where the vPE table lacates?
>
> Absolutely. This is a bug. I didn't spot it as my model only has a
> single ITS.
FWIW, I've pushed out an updated branch with this fixed as well as the
rest of the comments you had.
Thanks again,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2019-09-25 17:14 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-23 18:25 [PATCH 00/35] irqchip/gic-v4: GICv4.1 architecture support Marc Zyngier
2019-09-23 18:25 ` [PATCH 01/35] KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put Marc Zyngier
2019-09-23 18:25 ` [PATCH 02/35] irqchip/gic-v3-its: Factor out wait_for_syncr primitive Marc Zyngier
2019-09-24 8:58 ` Andrew Murray
2019-09-23 18:25 ` [PATCH 03/35] irqchip/gic-v3-its: Allow LPI invalidation via the DirectLPI interface Marc Zyngier
2019-09-26 14:57 ` Zenghui Yu
2019-09-26 15:34 ` Marc Zyngier
2019-09-26 16:17 ` Marc Zyngier
2019-09-27 6:59 ` Zenghui Yu
2019-09-23 18:25 ` [PATCH 04/35] irqchip/gic-v3: Detect GICv4.1 supporting RVPEID Marc Zyngier
2019-09-24 10:24 ` Andrew Murray
2019-09-24 10:49 ` Marc Zyngier
2019-09-24 11:00 ` Andrew Murray
2019-09-24 11:18 ` Marc Zyngier
2019-09-23 18:25 ` [PATCH 05/35] irqchip/gic-v3: Add GICv4.1 VPEID size discovery Marc Zyngier
2019-09-24 10:49 ` Andrew Murray
2019-09-24 11:00 ` Marc Zyngier
2019-09-23 18:25 ` [PATCH 06/35] irqchip/gic-v3-its: Make is_v4 use a TYPER copy Marc Zyngier
2019-09-23 18:25 ` [PATCH 07/35] irqchip/gic-v3-its: Kill its->ite_size and use TYPER copy instead Marc Zyngier
2019-09-23 18:25 ` [PATCH 08/35] irqchip/gic-v3-its: Kill its->device_ids " Marc Zyngier
2019-09-23 18:25 ` [PATCH 09/35] irqchip/gic-v3-its: Add get_vlpi_map() helper Marc Zyngier
2019-09-23 18:25 ` [PATCH 10/35] irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER) allocation Marc Zyngier
2019-09-25 13:04 ` Zenghui Yu
2019-09-25 14:41 ` Marc Zyngier
2019-09-25 17:14 ` Marc Zyngier [this message]
2019-09-26 15:19 ` Zenghui Yu
2019-09-26 15:57 ` Marc Zyngier
2019-09-26 16:27 ` Marc Zyngier
2019-09-27 2:01 ` Zenghui Yu
2019-09-27 1:59 ` Zenghui Yu
2019-09-23 18:25 ` [PATCH 11/35] irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP Marc Zyngier
2019-09-23 18:25 ` [PATCH 12/35] irqchip/gic-v4.1: Don't use the VPE proxy if RVPEID is set Marc Zyngier
2019-09-23 18:25 ` [PATCH 13/35] irqchip/gic-v4.1: Implement the v4.1 flavour of VMOVP Marc Zyngier
2019-09-23 18:25 ` [PATCH 14/35] irqchip/gic-v4.1: Plumb skeletal VPE irqchip Marc Zyngier
2019-09-23 18:25 ` [PATCH 15/35] irqchip/gic-v4.1: Add mask/unmask doorbell callbacks Marc Zyngier
2019-09-23 18:25 ` [PATCH 16/35] irqchip/gic-v4.1: Add VPE residency callback Marc Zyngier
2019-09-23 18:25 ` [PATCH 17/35] irqchip/gic-v4.1: Add VPE eviction callback Marc Zyngier
2019-09-23 18:25 ` [PATCH 18/35] irqchip/gic-v4.1: Add VPE INVALL callback Marc Zyngier
2019-09-23 18:25 ` [PATCH 19/35] irqchip/gic-v4.1: Suppress per-VLPI doorbell Marc Zyngier
2019-09-23 18:25 ` [PATCH 20/35] irqchip/gic-v4.1: Allow direct invalidation of VLPIs Marc Zyngier
2019-09-28 2:02 ` Zenghui Yu
2019-09-30 9:20 ` Marc Zyngier
2019-09-30 9:40 ` Zenghui Yu
2019-09-23 18:25 ` [PATCH 21/35] irqchip/gic-v4.1: Advertise support v4.1 to KVM Marc Zyngier
2019-09-23 18:25 ` [PATCH 22/35] irqchip/gic-v4.1: Map the ITS SGIR register page Marc Zyngier
2019-09-23 18:25 ` [PATCH 23/35] irqchip/gic-v4.1: Plumb skeletal VSGI irqchip Marc Zyngier
2019-09-23 18:25 ` [PATCH 24/35] irqchip/gic-v4.1: Add initial SGI configuration Marc Zyngier
2019-09-28 2:20 ` Zenghui Yu
2019-09-28 3:07 ` Zenghui Yu
2019-09-23 18:25 ` [PATCH 25/35] irqchip/gic-v4.1: Plumb mask/unmask SGI callbacks Marc Zyngier
2019-09-23 18:25 ` [PATCH 26/35] irqchip/gic-v4.1: Plumb get/set_irqchip_state " Marc Zyngier
2019-09-23 18:25 ` [PATCH 27/35] irqchip/gic-v4.1: Plumb set_vcpu_affinity " Marc Zyngier
2019-09-23 18:25 ` [PATCH 28/35] irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction layer Marc Zyngier
2019-09-23 18:26 ` [PATCH 29/35] irqchip/gic-v4.1: Add VSGI allocation/teardown Marc Zyngier
2019-09-23 18:26 ` [PATCH 30/35] irqchip/gic-v4.1: Add VSGI property setup Marc Zyngier
2019-09-23 18:26 ` [PATCH 31/35] irqchip/gic-v4.1: Eagerly vmap vPEs Marc Zyngier
2019-09-28 3:11 ` Zenghui Yu
2019-09-30 9:23 ` Marc Zyngier
2019-09-23 18:26 ` [PATCH 32/35] KVM: arm64: GICv4.1: Let doorbells be auto-enabled Marc Zyngier
2019-09-23 18:26 ` [PATCH 33/35] KVM: arm64: GICv4.1: Add direct injection capability to SGI registers Marc Zyngier
2019-09-23 18:26 ` [PATCH 34/35] KVM: arm64: GICv4.1: Configure SGIs as HW interrupts Marc Zyngier
2019-09-23 18:26 ` [PATCH 35/35] KVM: arm64: GICv4.1: Expose HW-based SGIs in debugfs Marc Zyngier
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=e64126d2adf7ea5fe5c75bd4bcdce6e0@www.loen.fr \
--to=maz@kernel.org \
--cc=jason@lakedaemon.net \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=tglx@linutronix.de \
--cc=yuzenghui@huawei.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
all inboxes | Powered by JetHome®