All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Christoffer Dall <cdall@linaro.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Cc: kvm@vger.kernel.org, Pekka Enberg <penberg@iki.fi>
Subject: Re: [PATCH v3 3/5] KVM: arm/arm64: Support arch timers with a userspace gic
Date: Thu, 6 Apr 2017 17:49:05 +0100	[thread overview]
Message-ID: <baaf0d40-222b-633e-77b6-75fc61f3e0ed@arm.com> (raw)
In-Reply-To: <20170405092815.22503-4-cdall@linaro.org>

On 05/04/17 10:28, Christoffer Dall wrote:
> From: Alexander Graf <agraf@suse.de>
> 
> If you're running with a userspace gic or other interrupt constroller

controller

> (that is no vgic in the kernel), then you have so far not been able to
> use the architected timers, because the output of the architected
> timers, which are driven inside the kernel, was a kernel-only construct
> between the arch timer code and the vgic.
> 
> This patch implements the new KVM_CAP_ARM_USER_IRQ feature, where we use a
> side channel on the kvm_run structure, run->s.regs.device_irq_level, to
> always notify userspace of the timer output levels when using a userspace
> irqchip.
> 
> This works by ensureing that before we enter the guest, if the timer

ensuring

> output level has changed compared to what we last told userspace, we
> don't enter the guest, but instead return to userspace to notify it of
> the new level.  If we are exiting, because of an MMIO for example, and
> the level changed at the same time, the value is also updated and
> userspace can sample the line as it needs.  This is nicely achieved
> simply always updating the timer_irq_level field after the main run
> loop.
> 
> Note that the kvm_timer_update_irq trace event is changed to show the
> host IRQ number for the timer instead of the guest IRQ number, because
> the kernel no longer know which IRQ userspace wires up the timer signal
> to.
> 
> Also note that this patch implements all required functionality but does
> not yet advertise the capability.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Otherwise looks good.

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/5] KVM: arm/arm64: Support arch timers with a userspace gic
Date: Thu, 6 Apr 2017 17:49:05 +0100	[thread overview]
Message-ID: <baaf0d40-222b-633e-77b6-75fc61f3e0ed@arm.com> (raw)
In-Reply-To: <20170405092815.22503-4-cdall@linaro.org>

On 05/04/17 10:28, Christoffer Dall wrote:
> From: Alexander Graf <agraf@suse.de>
> 
> If you're running with a userspace gic or other interrupt constroller

controller

> (that is no vgic in the kernel), then you have so far not been able to
> use the architected timers, because the output of the architected
> timers, which are driven inside the kernel, was a kernel-only construct
> between the arch timer code and the vgic.
> 
> This patch implements the new KVM_CAP_ARM_USER_IRQ feature, where we use a
> side channel on the kvm_run structure, run->s.regs.device_irq_level, to
> always notify userspace of the timer output levels when using a userspace
> irqchip.
> 
> This works by ensureing that before we enter the guest, if the timer

ensuring

> output level has changed compared to what we last told userspace, we
> don't enter the guest, but instead return to userspace to notify it of
> the new level.  If we are exiting, because of an MMIO for example, and
> the level changed at the same time, the value is also updated and
> userspace can sample the line as it needs.  This is nicely achieved
> simply always updating the timer_irq_level field after the main run
> loop.
> 
> Note that the kvm_timer_update_irq trace event is changed to show the
> host IRQ number for the timer instead of the guest IRQ number, because
> the kernel no longer know which IRQ userspace wires up the timer signal
> to.
> 
> Also note that this patch implements all required functionality but does
> not yet advertise the capability.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Otherwise looks good.

	M.
-- 
Jazz is not dead. It just smells funny...

  parent reply	other threads:[~2017-04-06 16:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05  9:28 [PATCH v3 0/5] Support userspace irqchip with arch timers Christoffer Dall
2017-04-05  9:28 ` Christoffer Dall
2017-04-05  9:28 ` [PATCH v3 1/5] KVM: arm/arm64: Cleanup the arch timer code's irqchip checking Christoffer Dall
2017-04-05  9:28   ` Christoffer Dall
2017-04-05  9:28 ` [PATCH v3 2/5] KVM: arm/arm64: Add ARM user space interrupt signaling ABI Christoffer Dall
2017-04-05  9:28   ` Christoffer Dall
2017-04-05  9:28 ` [PATCH v3 3/5] KVM: arm/arm64: Support arch timers with a userspace gic Christoffer Dall
2017-04-05  9:28   ` Christoffer Dall
2017-04-06  8:16   ` Alexander Graf
2017-04-06  8:16     ` Alexander Graf
2017-04-06  8:25     ` Marc Zyngier
2017-04-06  8:25       ` Marc Zyngier
2017-04-06  8:27       ` Alexander Graf
2017-04-06  8:27         ` Alexander Graf
2017-04-06 16:49   ` Marc Zyngier [this message]
2017-04-06 16:49     ` Marc Zyngier
2017-04-05  9:28 ` [PATCH v3 4/5] KVM: arm/arm64: Report PMU overflow interrupts to userspace irqchip Christoffer Dall
2017-04-05  9:28   ` Christoffer Dall
2017-04-06 17:12   ` Marc Zyngier
2017-04-06 17:12     ` Marc Zyngier
2017-04-06 19:04     ` Christoffer Dall
2017-04-06 19:04       ` Christoffer Dall
2017-04-05  9:28 ` [PATCH v3 5/5] KVM: arm/arm64: Advertise support for KVM_CAP_ARM_USER_IRQ Christoffer Dall
2017-04-05  9:28   ` Christoffer Dall
2017-04-06 17:13   ` Marc Zyngier
2017-04-06 17:13     ` Marc Zyngier
2017-04-06  8:28 ` [PATCH v3 0/5] Support userspace irqchip with arch timers Alexander Graf
2017-04-06  8:28   ` Alexander Graf
2017-04-06 17:31 ` Marc Zyngier
2017-04-06 17:31   ` Marc Zyngier
2017-04-06 19:13   ` Christoffer Dall
2017-04-06 19:13     ` Christoffer Dall

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=baaf0d40-222b-633e-77b6-75fc61f3e0ed@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=cdall@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=penberg@iki.fi \
    /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.