KVM ARM Archive on lore.kernel.org
 help / color / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <yuzenghui@huawei.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Jason Cooper <jason@lakedaemon.net>,
	linux-kernel@vger.kernel.org,
	Robert Richter <rrichter@marvell.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v3 05/32] irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER) allocation
Date: Mon, 20 Jan 2020 15:11:28 +0000
Message-ID: <3f1aad5c7f79b5ae5b87cef57523ec78@kernel.org> (raw)
In-Reply-To: <b4a78cea-4ba3-58fb-4121-44508e7ae384@huawei.com>

On 2020-01-20 14:03, Zenghui Yu wrote:
> Hi Marc,
> 
> On 2019/12/24 19:10, 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>
> 
> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
> 
> With two very minor concerns below.
> 
> [...]
> 
>> +static int allocate_vpe_l1_table(void)
>> +{
>> +	void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
>> +	u64 val, gpsz, npg, pa;
>> +	unsigned int psz = SZ_64K;
>> +	unsigned int np, epp, esz;
>> +	struct page *page;
>> +
>> +	if (!gic_rdists->has_rvpeid)
>> +		return 0;
>> +
>> +	/*
>> +	 * if VPENDBASER.Valid is set, disable any previously programmed
>> +	 * VPE by setting PendingLast while clearing Valid. This has the
>> +	 * effect of making sure no doorbell will be generated and we can
>> +	 * then safely clear VPROPBASER.Valid.
>> +	 */
>> +	if (gits_read_vpendbaser(vlpi_base + GICR_VPENDBASER) & 
>> GICR_VPENDBASER_Valid)
>> +		gits_write_vpendbaser(GICR_VPENDBASER_PendingLast,
>> +				      vlpi_base + GICR_VPENDBASER);
> 
> I'm confused here.  The Valid field resets to 0.  Under which scenario
> will the Valid==1 while we're doing initialization for this RD?

The cases I'm worried about are things like kexec or cpu hotplug,
where we could find that the RD programming is still valid, one way
or another. This is unlikely to hit in practice, but who knows...

> 
>> +
>> +	/*
>> +	 * If we can inherit the configuration from another RD, let's do
>> +	 * so. Otherwise, we have to go through the allocation process. We
>> +	 * assume that all RDs have the exact same requirements, as
>> +	 * nothing will work otherwise.
>> +	 */
>> +	val = 
>> inherit_vpe_l1_table_from_rd(&gic_data_rdist()->vpe_table_mask);
>> +	if (val & GICR_VPROPBASER_4_1_VALID)
>> +		goto out;
>> +
>> +	gic_data_rdist()->vpe_table_mask = kzalloc(sizeof(cpumask_t), 
>> GFP_KERNEL);
>> +	if (!gic_data_rdist()->vpe_table_mask)
>> +		return -ENOMEM;
>> +
>> +	val = inherit_vpe_l1_table_from_its();
>> +	if (val & GICR_VPROPBASER_4_1_VALID)
>> +		goto out;
>> +
>> +	/* First probe the page size */
>> +	val = FIELD_PREP(GICR_VPROPBASER_4_1_PAGE_SIZE, GIC_PAGE_SIZE_64K);
>> +	gits_write_vpropbaser(val, vlpi_base + GICR_VPROPBASER);
>> +	val = gits_read_vpropbaser(vlpi_base + GICR_VPROPBASER);
>> +	gpsz = FIELD_GET(GICR_VPROPBASER_4_1_PAGE_SIZE, val);
>> +	esz = FIELD_GET(GICR_VPROPBASER_4_1_ENTRY_SIZE, val);
>> +
>> +	switch (gpsz) {
>> +	default:
>> +		gpsz = GIC_PAGE_SIZE_4K;
>> +		/* fall through */
>> +	case GIC_PAGE_SIZE_4K:
>> +		psz = SZ_4K;
>> +		break;
>> +	case GIC_PAGE_SIZE_16K:
>> +		psz = SZ_16K;
>> +		break;
>> +	case GIC_PAGE_SIZE_64K:
>> +		psz = SZ_64K;
>> +		break;
>> +	}
>> +
>> +	/*
>> +	 * Start populating the register from scratch, including RO fields
>> +	 * (which we want to print in debug cases...)
>> +	 */
>> +	val = 0;
>> +	val |= FIELD_PREP(GICR_VPROPBASER_4_1_PAGE_SIZE, gpsz);
>> +	val |= FIELD_PREP(GICR_VPROPBASER_4_1_ENTRY_SIZE, esz);
>> +
>> +	/* How many entries per GIC page? */
>> +	esz++;
>> +	epp = psz / (esz * SZ_8);
>> +
>> +	/*
>> +	 * If we need more than just a single L1 page, flag the table
>> +	 * as indirect and compute the number of required L1 pages.
>> +	 */
>> +	if (epp < ITS_MAX_VPEID) {
>> +		int nl2;
>> +
>> +		gic_rdists->flags |= RDIST_FLAGS_VPE_INDIRECT;
> 
> This flag is set but not used, can we just drop it?

Yes, good point. I can't even remember what I had in mind with this
flag, so it can't be that important! ;-).

I'll clean that up.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply index

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-24 11:10 [PATCH v3 00/32] irqchip/gic-v4: GICv4.1 architecture support Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 01/32] irqchip/gic-v3: Detect GICv4.1 supporting RVPEID Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 02/32] irqchip/gic-v3: Add GICv4.1 VPEID size discovery Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 03/32] irqchip/gic-v3: Workaround Cavium TX1 erratum when reading GICD_TYPER2 Marc Zyngier
2020-03-09 22:11   ` Robert Richter
2020-03-10 11:41     ` Marc Zyngier
2020-03-10 12:34       ` Robert Richter
2020-03-11  8:45       ` Robert Richter
2020-03-11  9:03         ` Marc Zyngier
2020-03-11  9:18           ` Robert Richter
2019-12-24 11:10 ` [PATCH v3 04/32] irqchip/gic-v3: Use SGIs without active state if offered Marc Zyngier
2019-12-28  8:56   ` Zenghui Yu
2019-12-28 10:36     ` Marc Zyngier
2019-12-30  3:50       ` Zenghui Yu
2019-12-24 11:10 ` [PATCH v3 05/32] irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER) allocation Marc Zyngier
2020-01-20 14:03   ` Zenghui Yu
2020-01-20 15:11     ` Marc Zyngier [this message]
2020-01-22  2:59   ` Zenghui Yu
2019-12-24 11:10 ` [PATCH v3 06/32] irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 07/32] irqchip/gic-v4.1: Don't use the VPE proxy if RVPEID is set Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 08/32] irqchip/gic-v4.1: Implement the v4.1 flavour of VMOVP Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 09/32] irqchip/gic-v4.1: Plumb skeletal VPE irqchip Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 10/32] irqchip/gic-v4.1: Add mask/unmask doorbell callbacks Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 11/32] irqchip/gic-v4.1: Add VPE residency callback Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 12/32] irqchip/gic-v4.1: Add VPE eviction callback Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 13/32] irqchip/gic-v4.1: Add VPE INVALL callback Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 14/32] irqchip/gic-v4.1: Suppress per-VLPI doorbell Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 15/32] irqchip/gic-v4.1: Allow direct invalidation of VLPIs Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 16/32] irqchip/gic-v4.1: Advertise support v4.1 to KVM Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 17/32] irqchip/gic-v4.1: Map the ITS SGIR register page Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 18/32] irqchip/gic-v4.1: Plumb skeletal VSGI irqchip Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 19/32] irqchip/gic-v4.1: Add initial SGI configuration Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 20/32] irqchip/gic-v4.1: Plumb mask/unmask SGI callbacks Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 21/32] irqchip/gic-v4.1: Plumb get/set_irqchip_state " Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 22/32] irqchip/gic-v4.1: Plumb set_vcpu_affinity " Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 23/32] irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction layer Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 24/32] irqchip/gic-v4.1: Add VSGI allocation/teardown Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 25/32] irqchip/gic-v4.1: Add VSGI property setup Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 26/32] irqchip/gic-v4.1: Eagerly vmap vPEs Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 27/32] KVM: arm64: GICv4.1: Let doorbells be auto-enabled Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 28/32] KVM: arm64: GICv4.1: Add direct injection capability to SGI registers Marc Zyngier
2019-12-28  9:19   ` Zenghui Yu
2019-12-28 10:41     ` Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 29/32] KVM: arm64: GICv4.1: Allow SGIs to switch between HW and SW interrupts Marc Zyngier
2020-01-15  2:49   ` Shaokun Zhang
2020-01-15  3:49     ` Zenghui Yu
2020-01-15 13:32       ` Marc Zyngier
2020-01-15 13:49         ` Zenghui Yu
2020-01-16  6:13         ` Shaokun Zhang
2020-01-15 13:17     ` Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 30/32] KVM: arm64: GICv4.1: Plumb SGI implementation selection in the distributor Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 31/32] KVM: arm64: GICv4.1: Reload VLPI configuration on distributor enable/disable Marc Zyngier
2019-12-24 11:10 ` [PATCH v3 32/32] 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=3f1aad5c7f79b5ae5b87cef57523ec78@kernel.org \
    --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=rrichter@marvell.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

KVM ARM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvmarm/0 kvmarm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvmarm kvmarm/ https://lore.kernel.org/kvmarm \
		kvmarm@lists.cs.columbia.edu
	public-inbox-index kvmarm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/edu.columbia.cs.lists.kvmarm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git