kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoffer Dall <cdall@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2 1/9] KVM: arm64: Allow creating the PMU without the in-kernel GIC
Date: Wed, 24 May 2017 13:45:34 +0200	[thread overview]
Message-ID: <20170524114534.GB7991@cbox> (raw)
In-Reply-To: <4cf8f05e-1af1-eaed-151f-54e7a60d7b63@arm.com>

On Wed, May 24, 2017 at 10:16:56AM +0100, Marc Zyngier wrote:
> On 24/05/17 09:38, Christoffer Dall wrote:
> > On Tue, May 23, 2017 at 05:52:01PM +0100, Marc Zyngier wrote:
> >> On 16/05/17 19:45, Christoffer Dall wrote:
> >>> Since we got support for devices in userspace which allows reporting the
> >>> PMU overflow output status to userspace, we should actually allow
> >>> creating the PMU on systems without an in-kernel irqchip, which in turn
> >>> requires us to slightly clarify error codes for the ABI and move things
> >>> around for the initialization phase.
> >>>
> >>> Signed-off-by: Christoffer Dall <cdall@linaro.org>
> >>> ---
> >>>  Documentation/virtual/kvm/devices/vcpu.txt | 16 +++++++++-------
> >>>  virt/kvm/arm/pmu.c                         | 30 ++++++++++++++++++++----------
> >>>  2 files changed, 29 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
> >>> index 02f5068..352af6e 100644
> >>> --- a/Documentation/virtual/kvm/devices/vcpu.txt
> >>> +++ b/Documentation/virtual/kvm/devices/vcpu.txt
> >>> @@ -16,7 +16,9 @@ Parameters: in kvm_device_attr.addr the address for PMU overflow interrupt is a
> >>>  Returns: -EBUSY: The PMU overflow interrupt is already set
> >>>           -ENXIO: The overflow interrupt not set when attempting to get it
> >>>           -ENODEV: PMUv3 not supported
> >>> -         -EINVAL: Invalid PMU overflow interrupt number supplied
> >>> +         -EINVAL: Invalid PMU overflow interrupt number supplied or
> >>> +                  trying to set the IRQ number without using an in-kernel
> >>> +                  irqchip.
> >>>  
> >>>  A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
> >>>  number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
> >>> @@ -25,11 +27,11 @@ all vcpus, while as an SPI it must be a separate number per vcpu.
> >>>  
> >>>  1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
> >>>  Parameters: no additional parameter in kvm_device_attr.addr
> >>> -Returns: -ENODEV: PMUv3 not supported
> >>> -         -ENXIO: PMUv3 not properly configured as required prior to calling this
> >>> -                 attribute
> >>> +Returns: -ENODEV: PMUv3 not supported or GIC not initialized
> >>> +         -ENXIO: PMUv3 not properly configured or in-kernel irqchip not
> >>> +                 conigured as required prior to calling this attribute
> >>
> >>                     configured
> >>
> >>>           -EBUSY: PMUv3 already initialized
> >>>  
> >>> -Request the initialization of the PMUv3.  This must be done after creating the
> >>> -in-kernel irqchip.  Creating a PMU with a userspace irqchip is currently not
> >>> -supported.
> >>> +Request the initialization of the PMUv3.  If using the PMUv3 with an in-kernel
> >>> +virtual GIC implementation, this must be done after initializing the in-kernel
> >>> +irqchip.
> >>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> >>> index 4b43e7f..7209185 100644
> >>> --- a/virt/kvm/arm/pmu.c
> >>> +++ b/virt/kvm/arm/pmu.c
> >>> @@ -456,21 +456,25 @@ static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
> >>>  	if (!kvm_arm_support_pmu_v3())
> >>>  		return -ENODEV;
> >>>  
> >>> -	/*
> >>> -	 * We currently require an in-kernel VGIC to use the PMU emulation,
> >>> -	 * because we do not support forwarding PMU overflow interrupts to
> >>> -	 * userspace yet.
> >>> -	 */
> >>> -	if (!irqchip_in_kernel(vcpu->kvm) || !vgic_initialized(vcpu->kvm))
> >>> -		return -ENODEV;
> >>> -
> >>> -	if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features) ||
> >>> -	    !kvm_arm_pmu_irq_initialized(vcpu))
> >>> +	if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
> >>>  		return -ENXIO;
> >>>  
> >>>  	if (kvm_arm_pmu_v3_ready(vcpu))
> >>>  		return -EBUSY;
> >>>  
> >>> +	if (irqchip_in_kernel(vcpu->kvm)) {
> >>> +		/*
> >>> +		 * If using the PMU with an in-kernel virtual GIC
> >>> +		 * implementation, we require the GIC to be already
> >>> +		 * initialized when initializing the PMU.
> >>> +		 */
> >>> +		if (!vgic_initialized(vcpu->kvm))
> >>> +			return -ENODEV;
> >>> +
> >>> +		if (!kvm_arm_pmu_irq_initialized(vcpu))
> >>> +			return -ENXIO;
> >>> +	}
> >>> +
> >>
> >> Do we also need to prevent a vgic to be created if the PMU has been
> >> initialized beforehand?
> >>
> > 
> > Sigh.  We probably have to.
> > 
> > I don't like having a cross-VGIC-PMU check, but we could do something
> > like setting a flag on the kvm struct so that irqchip_in_user() always
> > return true, and if that is set, it is not possible to create the VGIC.
> > 
> > Alternatively we can make the PMU init a no-op, and try to enable it via
> > the first-vcpu-run path, like the timer, and check that everything lines
> > up then (i.e. you have in-kernel irqchip with a non-conflicting irq
> > number or you have a userspace irqchip).
> 
> I like this second solution better, as it gives us a common approach to
> similar problems.

Yes, but on the other hand it's a bit like the lazy init stuff, where we
defer things to happen at some point in time, and the whole PMU init
thing was to avoid that.  On the first hand, it seems to work well for
lots of things, so why not...


> Would that also help with not having to implement the
> allocator you introduced in patches 6-9 (which I haven't reviewed yet)?
> 

Not really.  I mean, we could add some cross calls between the timer and
PMU code, but I think that's fairly disgusting, and it doesn't prevent
userspace from fiddling with an interrupt signal used in the kernel
anyway.

With patchs 6-9, I feel like we should take one of two overall stands;
either we don't care that userspace can wire things up share an
interrupt line, even with in-kernel driven devices, as it would be the
equivalent of putting an OR gate before the GIC in hardware (not that I
recommend anyone doing that), or we should implement the full story and
prevent userspace from ever shooting itself in the foot.

Thanks,
-Christoffer

  reply	other threads:[~2017-05-24 11:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-16 18:45 [PATCH v2 0/9] Userspace timer IRQ number control and PMU with userspace-gic Christoffer Dall
2017-05-16 18:45 ` [PATCH v2 1/9] KVM: arm64: Allow creating the PMU without the in-kernel GIC Christoffer Dall
2017-05-23 16:52   ` Marc Zyngier
2017-05-24  8:38     ` Christoffer Dall
2017-05-24  9:16       ` Marc Zyngier
2017-05-24 11:45         ` Christoffer Dall [this message]
2017-05-24 16:37           ` Marc Zyngier
2017-06-01 10:53             ` Christoffer Dall
2017-05-16 18:45 ` [PATCH v2 2/9] KVM: arm: Handle VCPU device attributes in guest.c Christoffer Dall
2017-05-23 16:53   ` Marc Zyngier
2017-05-16 18:45 ` [PATCH v2 3/9] KVM: arm/arm64: Move irq_is_ppi() to header file Christoffer Dall
2017-05-23 17:10   ` Marc Zyngier
2017-05-16 18:45 ` [PATCH v2 4/9] KVM: arm/arm64: Move timer IRQ default init to arch_timer.c Christoffer Dall
2017-05-23 17:18   ` Marc Zyngier
2017-05-16 18:45 ` [PATCH v2 5/9] KVM: arm/arm64: Allow setting the timer IRQ numbers from userspace Christoffer Dall
2017-05-23 17:45   ` Marc Zyngier
2017-05-16 18:45 ` [PATCH v2 6/9] KVM: arm/arm64: Introduce an allocator for in-kernel irq lines Christoffer Dall
2017-05-16 18:45 ` [PATCH v2 7/9] KVM: arm/arm64: Check if irq lines to the GIC are already used Christoffer Dall
2017-05-16 18:45 ` [PATCH v2 8/9] KVM: arm/arm64: Disallow userspace control of in-kernel IRQ lines Christoffer Dall
2017-05-16 18:45 ` [PATCH v2 9/9] KVM: arm/arm64: Don't assume initialized vgic when setting PMU IRQ 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=20170524114534.GB7991@cbox \
    --to=cdall@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.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;
as well as URLs for NNTP newsgroup(s).