KVM ARM Archive on lore.kernel.org
 help / color / Atom feed
From: Zenghui Yu <yuzenghui@huawei.com>
To: Marc Zyngier <maz@kernel.org>
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 04/32] irqchip/gic-v3: Use SGIs without active state if offered
Date: Mon, 30 Dec 2019 11:50:43 +0800
Message-ID: <33df30e8-8ce8-fde1-2e9f-9ef4eda4f563@huawei.com> (raw)
In-Reply-To: <20191228103301.147f541c@why>

Hi Marc,

On 2019/12/28 18:36, Marc Zyngier wrote:
> On Sat, 28 Dec 2019 16:56:54 +0800
> Zenghui Yu <yuzenghui@huawei.com> wrote:
> 
> Hi Zenghui,
> 
>> Hi Marc,
>>
>> On 2019/12/24 19:10, Marc Zyngier wrote:
>>> If running under control of a hypervisor that implements GICv4.1
>>> SGIs, allow the hypervisor to use them at the expense of loosing
>>> the Active state (which we don't care about for SGIs).
>>>
>>> This is trivially done by checking for GICD_TYPER2.nASSGIcap, and
>>> setting GICD_CTLR.nASSGIreq when enabling Group-1 interrupts.
>>>
>>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>>> ---
>>>    drivers/irqchip/irq-gic-v3.c       | 10 ++++++++--
>>>    include/linux/irqchip/arm-gic-v3.h |  2 ++
>>>    2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>>> index 640d4db65b78..624f351c0362 100644
>>> --- a/drivers/irqchip/irq-gic-v3.c
>>> +++ b/drivers/irqchip/irq-gic-v3.c
>>> @@ -724,6 +724,7 @@ static void __init gic_dist_init(void)
>>>    	unsigned int i;
>>>    	u64 affinity;
>>>    	void __iomem *base = gic_data.dist_base;
>>> +	u32 val;
>>>    >   	/* Disable the distributor */
>>>    	writel_relaxed(0, base + GICD_CTLR);
>>> @@ -756,9 +757,14 @@ static void __init gic_dist_init(void)
>>>    	/* Now do the common stuff, and wait for the distributor to drain */
>>>    	gic_dist_config(base, GIC_LINE_NR, gic_dist_wait_for_rwp);
>>>    > +	val = GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1;
>>> +	if (gic_data.rdists.gicd_typer2 & GICD_TYPER2_nASSGIcap) {
>>> +		pr_info("Enabling SGIs without active state\n");
>>> +		val |= GICD_CTLR_nASSGIreq;
>>> +	}
>>> +
>>>    	/* Enable distributor with ARE, Group1 */
>>> -	writel_relaxed(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1,
>>> -		       base + GICD_CTLR);
>>> +	writel_relaxed(val, base + GICD_CTLR);
>>>    >   	/*
>>>    	 * Set all global interrupts to the boot CPU only. ARE must be
>>> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
>>> index 9dfe64189d99..72b69f4e6c7b 100644
>>> --- a/include/linux/irqchip/arm-gic-v3.h
>>> +++ b/include/linux/irqchip/arm-gic-v3.h
>>> +#define GICD_CTLR_nASSGIreq		(1U << 8)
>>
>>> +#define GICD_TYPER2_nASSGIcap		(1U << 8)
>>
>> I thought these two bits are newly added in the specification, which is
>> not available yet... until I've reached patch 29 and 30.
>>
>> So they are actually some "kvm-implemented" bits and can only be used by
>> the KVM guests. I have two questions now:
>>
>> 1) As per the latest GIC specification, these two bits are Reserved
>>      (RAZ/WI) from host's perspective, which is good for now. But will
>>      they be (unexpectedly) used one day by the future architecture?
> 
> These bits are now assigned by the latest revision of the GICv4.1 spec,
> and are roughly defined as you reversed engineered them below.

(Ah, so all what I'm having in the hand is a GICv4.0.5 ;-).

> The idea is that unmodified SW expects SGIs to have an active state,
> because that's the way it has always been so far. Any architecturally
> compliant hypervisor must implement an active state for SGIs.
> 
> Now, there are obvious benefits in having HW-accelerated SGI delivery,
> which for GICv4.1 comes at the expense of loosing the active state.
> 
> So we need a way to expose the fact that the hypervisor *can* support
> non-active-state SGIs (hence the GICD_TYPER2.nASSGIcap bit), and a way
> for the guest to say "I'm OK with losing the active state for SGIs",
> which corresponds to the GICD_CTLR.nASSGIreq bit.

Thanks for the explanation!

> Note that this isn't a property that ever needs to be exposed by the
> HW, but one that has been architected for the sole benefit of
> hypervisors and guests (a HW implementation would keep them as RAZ/WI).

Yeah, I can understand this point.

>> 2) Only Linux guest will check and make use of these bits now. What if
>>      some non-Linux guests wants to run with KVM and use the GICv4.1 based
>>      vSGIs?  Their developers might have no interests reading at the KVM
>>      code... so what about plumbing some descriptions about these bits
>>      into somewhere in the documentation (or code)?  Like below, mostly
>>      copied from your commit messages:
>>
>> ---8<---
>>
>> // Roughly writing, for the ease of reviewing the later patches.
>>
>> No-Active-State SGIs (?) Related Field Descriptions
>> 	--From Guest's Perspective
>>
>> With GICv4.1, KVM exposes two single bit (in GICD_TYPER2 and GICD_CTLR
>> respectively) for guests, which can be used to probe the GICv4.1 based
>> SGIs support on hypervisor and choose whether guests want the good old
>> SGIs with an active state, or the new, HW-based ones that do not have
>> one.
>>
>> GICD_TYPER2.nASSGIcap, bit [8]
>>
>>       Indicates whether guests are running under control of a hypervisor
>>       that implements GICv4.1 SGIs, allow the hypervisor to use them at
>>       the expense of loosing the Active state.
>>
>>       0b0    GICv4.1 SGIs capability is not offered by hypervisor.
>>
>>       0b1    GICv4.1 SGIs capability is offered by hypervisor.
>>
>>       This field is RO.
>>
>>
>> GICD_CTLR.nASSGIreq, bit [8]
>>
>>       Indicates whether guests wants to use HW-based SGIs without Active
>>       state if the GICv4.1 SGI capability is offered by hypervisor.
>>       Hypervisor will then try to satisfy the request and switch between
>>       HW/SW delivered SGIs.
>>
>>       0b0    If read, indicated that guest is using the old SW-emulated
>>              SGIs.
>>              If write, indicates that guest requests to use the old
>>              SW-emulated SGIs.
>>
>>       0b1    If read, indicates that guest is using the new HW-based SGIs.
>>              If write, indicates that guest requests to use the new
>>              HW-based SGIs. If GICD_TYPER2.nASSGIcap is 0, the write has
>>              no effect.
>>
>>       Changing this bit is UNPREDICTABLE if the Distributor is enabled.
>>       KVM may just treat this bit as RO when Distributor stays enabled.
>>
>>
>> See gic_dist_init() in drivers/irqchip/irq-gic-v3.c for an example that
>> how Linux guest (since 5.6?) makes use of these bits and benefits from
>> the GICv4.1 based vSGIs.
>>
>> These two bits are Reserved (RAZ/WI) from host's perspective, which is
>> good for now.
> 
> This write-up is sensible, but it would be a duplication of the
> architecture spec once it is publicly available. As much as possible,
> I'd like not to duplicate information, as the are bound to diverge as
> the architecture spec gets amended. How about we add this to the commit
> message instead, as a placeholder until the GICv4.1 doc is available
> (hopefully some time next year)?

Good idea, I'm all for it.

It will (at least) help other reviewers to easily realize what is going
on between guests and the hypervisor.


Thanks,
Zenghui

_______________________________________________
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 [this message]
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
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=33df30e8-8ce8-fde1-2e9f-9ef4eda4f563@huawei.com \
    --to=yuzenghui@huawei.com \
    --cc=jason@lakedaemon.net \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maz@kernel.org \
    --cc=rrichter@marvell.com \
    --cc=tglx@linutronix.de \
    /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