kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Eric Auger <eric.auger@redhat.com>,
	Hector Martin <marcan@marcan.st>,
Subject: Re: [PATCH v3 3/9] KVM: arm64: vgic: Be tolerant to the lack of maintenance interrupt
Date: Mon, 10 May 2021 18:44:49 +0100	[thread overview]
Message-ID: <87sg2uo54e.wl-maz@kernel.org> (raw)
In-Reply-To: <20210510161907.GD92897@C02TD0UTHF1T.local>

On Mon, 10 May 2021 17:19:07 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, May 10, 2021 at 02:48:18PM +0100, Marc Zyngier wrote:
> > As it turns out, not all the interrupt controllers are able to
> > expose a vGIC maintenance interrupt as a distrete signal.
> > And to be fair, it doesn't really matter as all we require is
> > for *something* to kick us out of guest mode out way or another.
> > 
> > On systems that do not expose a maintenance interrupt as such,
> > there are two outcomes:
> > 
> > - either the virtual CPUIF does generate an interrupt, and
> >   by the time we are back to the host the interrupt will have long
> >   been disabled (as we set ICH_HCR_EL2.EN to 0 on exit). In this case,
> >   interrupt latency is as good as it gets.
> > 
> > - or some other event (physical timer) will take us out of the guest
> >   anyway, and the only drawback is a bad interrupt latency.
> IIRC we won't have a a guaranteed schedular tick for NO_HZ_FULL, so in
> that case we'll either need to set a period software maintenance
> interrupt, or reject this combination at runtime (either when trying to
> isolate the dynticks CPUs, or when trying to create a VM).

That's a good point.

On sensible systems, the maintenance interrupt is a standard GIC PPI
that requires enabling, and that is all that KVM requires (the
maintenance interrupt is only used as an exit mechanism and will be
disabled before reaching the handler).

On the M1, owing to the lack of a per-CPU interrupt controller, there
is nothing to enable. The virtual CPU interface will fire at will and
take us out of the guest in a timely manner.

So maybe instead of relaxing the requirement for a maintenance
interrupt, we should only bypass the checks if the root interrupt
controller advertises that it is safe to do so, making it a
M1-specific hack.



Without deviation from the norm, progress is not possible.

  reply	other threads:[~2021-05-10 17:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10 13:48 [PATCH v3 0/9] KVM: arm64: Initial host support for the Apple M1 Marc Zyngier
2021-05-10 13:48 ` [PATCH v3 1/9] irqchip/gic: Split vGIC probing information from the GIC code Marc Zyngier
2021-05-18 16:51   ` Alexandru Elisei
2021-05-10 13:48 ` [PATCH v3 2/9] KVM: arm64: Handle physical FIQ as an IRQ while running a guest Marc Zyngier
2021-05-20 17:46   ` Alexandru Elisei
2021-05-10 13:48 ` [PATCH v3 3/9] KVM: arm64: vgic: Be tolerant to the lack of maintenance interrupt Marc Zyngier
2021-05-10 16:19   ` Mark Rutland
2021-05-10 17:44     ` Marc Zyngier [this message]
2021-05-11 11:13       ` Mark Rutland
2021-05-10 13:48 ` [PATCH v3 4/9] KVM: arm64: vgic: Let an interrupt controller advertise lack of HW deactivation Marc Zyngier
2021-05-21 17:01   ` Alexandru Elisei
2021-05-24 17:17     ` Marc Zyngier
2021-05-10 13:48 ` [PATCH v3 5/9] KVM: arm64: vgic: move irq->get_input_level into an ops structure Marc Zyngier
2021-05-10 13:48 ` [PATCH v3 6/9] KVM: arm64: vgic: Implement SW-driven deactivation Marc Zyngier
2021-05-24 16:53   ` Alexandru Elisei
2021-05-24 17:43     ` Marc Zyngier
2021-05-10 13:48 ` [PATCH v3 7/9] KVM: arm64: timer: Refactor IRQ configuration Marc Zyngier
2021-05-14 12:46   ` Zenghui Yu
2021-05-24 17:48     ` Marc Zyngier
2021-05-10 13:48 ` [PATCH v3 8/9] KVM: arm64: timer: Add support for SW-based deactivation Marc Zyngier
2021-05-10 13:48 ` [PATCH v3 9/9] irqchip/apple-aic: Advertise some level of vGICv3 compatibility Marc Zyngier
2021-05-12 16:22 ` [PATCH v3 0/9] KVM: arm64: Initial host support for the Apple M1 Alexandru Elisei
2021-05-12 16:33   ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sg2uo54e.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=eric.auger@redhat.com \
    --cc=james.morse@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marcan@marcan.st \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \


* 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;
as well as URLs for NNTP newsgroup(s).