linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: mark.rutland@arm.com, sumit.garg@linaro.org, kvm@vger.kernel.org,
	Julien Thierry <julien.thierry@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	catalin.marinas@arm.com,
	Suzuki K Pouloze <suzuki.poulose@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, swboyd@chromium.org,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	will@kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 5/7] KVM: arm64: pmu: Make overflow handler NMI safe
Date: Wed, 30 Sep 2020 12:46:52 +0100	[thread overview]
Message-ID: <3379a8af-67ae-f71f-316d-3baa5fadc6dd@arm.com> (raw)
In-Reply-To: <14a0562fee95d5c7aa5bc6b67d213858@kernel.org>

Hello,

On 9/29/20 9:11 AM, Marc Zyngier wrote:
> On 2020-09-24 12:07, Alexandru Elisei wrote:
>> From: Julien Thierry <julien.thierry@arm.com>
>>
>> kvm_vcpu_kick() is not NMI safe. When the overflow handler is called from
>> NMI context, defer waking the vcpu to an irq_work queue.
>>
>> A vcpu can be freed while it's not running by kvm_destroy_vm(). Prevent
>> running the irq_work for a non-existent vcpu by calling irq_work_sync() on
>> the PMU destroy path.
>>
>> Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: James Morse <james.morse@arm.com>
>> Cc: Suzuki K Pouloze <suzuki.poulose@arm.com>
>> Cc: kvm@vger.kernel.org
>> Cc: kvmarm@lists.cs.columbia.edu
>> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
>> Tested-by: Sumit Garg <sumit.garg@linaro.org> (Developerbox)
>> [Alexandru E.: Added irq_work_sync()]
>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>> ---
>> I suggested in v6 that I will add an irq_work_sync() to
>> kvm_pmu_vcpu_reset(). It turns out it's not necessary: a vcpu reset is done
>> by the vcpu being reset with interrupts enabled, which means all the work
>> has had a chance to run before the reset takes place.
>
> I don't understand your argument about interrupts being enabled. The real
> reason for not needing any synchronization is that all that the queued work
> does is to kick the vcpu. Given that the vcpu is resetting, no amount of
> kicking is going to change anything (it is already outside of the guest).
>
> Things are obviously different on destroy, where the vcpu is actively going
> away and we need to make sure we don't use stale data.

Like you and Will noticed, the above really doesn't make much sense. The reason we
don't need to wait for the irq_work to be finished on reset is indeed that the
vcpu isn't freed, so we will never trigger a use-after-free bug.

>
>>
>>  arch/arm64/kvm/pmu-emul.c | 26 +++++++++++++++++++++++++-
>>  include/kvm/arm_pmu.h     |  1 +
>>  2 files changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
>> index f0d0312c0a55..81916e360b1e 100644
>> --- a/arch/arm64/kvm/pmu-emul.c
>> +++ b/arch/arm64/kvm/pmu-emul.c
>> @@ -269,6 +269,7 @@ void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu)
>>
>>      for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++)
>>          kvm_pmu_release_perf_event(&pmu->pmc[i]);
>> +    irq_work_sync(&vcpu->arch.pmu.overflow_work);
>>  }
>>
>>  u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>> @@ -433,6 +434,22 @@ void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu)
>>      kvm_pmu_update_state(vcpu);
>>  }
>>
>> +/**
>> + * When perf interrupt is an NMI, we cannot safely notify the vcpu
>> corresponding
>> + * to the event.
>> + * This is why we need a callback to do it once outside of the NMI context.
>> + */
>> +static void kvm_pmu_perf_overflow_notify_vcpu(struct irq_work *work)
>> +{
>> +    struct kvm_vcpu *vcpu;
>> +    struct kvm_pmu *pmu;
>> +
>> +    pmu = container_of(work, struct kvm_pmu, overflow_work);
>> +    vcpu = kvm_pmc_to_vcpu(pmu->pmc);
>> +
>> +    kvm_vcpu_kick(vcpu);
>> +}
>> +
>>  /**
>>   * When the perf event overflows, set the overflow status and inform the vcpu.
>>   */
>> @@ -465,7 +482,11 @@ static void kvm_pmu_perf_overflow(struct
>> perf_event *perf_event,
>>
>>      if (kvm_pmu_overflow_status(vcpu)) {
>>          kvm_make_request(KVM_REQ_IRQ_PENDING, vcpu);
>> -        kvm_vcpu_kick(vcpu);
>> +
>> +        if (!in_nmi())
>> +            kvm_vcpu_kick(vcpu);
>> +        else
>> +            irq_work_queue(&vcpu->arch.pmu.overflow_work);
>>      }
>>
>>      cpu_pmu->pmu.start(perf_event, PERF_EF_RELOAD);
>> @@ -764,6 +785,9 @@ static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
>>              return ret;
>>      }
>>
>> +    init_irq_work(&vcpu->arch.pmu.overflow_work,
>> +              kvm_pmu_perf_overflow_notify_vcpu);
>> +
>>      vcpu->arch.pmu.created = true;
>>      return 0;
>>  }
>> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
>> index 6db030439e29..dbf4f08d42e5 100644
>> --- a/include/kvm/arm_pmu.h
>> +++ b/include/kvm/arm_pmu.h
>> @@ -27,6 +27,7 @@ struct kvm_pmu {
>>      bool ready;
>>      bool created;
>>      bool irq_level;
>> +    struct irq_work overflow_work;
>
> Nit: placing this new field right after the pmc array would avoid creating
> an unnecessary padding in the structure. Not a big deal, and definitely
> something we can sort out when applying the patch.

That makes sense, overflow_work must be aligned to 8 bytes, and there are 16
elements in the pmc array, which means no padding is required for the
overflow_work field.

Thanks,
Alex

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-09-30 11:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 11:06 [PATCH v7 0/7] arm_pmu: Use NMI for perf interrupt Alexandru Elisei
2020-09-24 11:07 ` [PATCH v7 1/7] arm64: perf: Add missing ISB in armv8pmu_enable_counter() Alexandru Elisei
2020-09-24 11:07 ` [PATCH v7 2/7] arm64: perf: Avoid PMXEV* indirection Alexandru Elisei
2020-09-24 11:07 ` [PATCH v7 3/7] arm64: perf: Remove PMU locking Alexandru Elisei
2020-09-24 11:07 ` [PATCH v7 4/7] arm64: perf: Defer irq_work to IPI_IRQ_WORK Alexandru Elisei
2020-09-24 11:07 ` [PATCH v7 5/7] KVM: arm64: pmu: Make overflow handler NMI safe Alexandru Elisei
2020-09-28 17:57   ` Will Deacon
2020-09-30 12:37     ` Alexandru Elisei
2020-09-29  8:11   ` Marc Zyngier
2020-09-30 11:46     ` Alexandru Elisei [this message]
2020-09-24 11:07 ` [PATCH v7 6/7] arm_pmu: Introduce pmu_irq_ops Alexandru Elisei
2020-09-24 11:07 ` [PATCH v7 7/7] arm_pmu: arm64: Use NMIs for PMU Alexandru Elisei
2020-09-28 22:13 ` [PATCH v7 0/7] arm_pmu: Use NMI for perf interrupt Will Deacon

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=3379a8af-67ae-f71f-316d-3baa5fadc6dd@arm.com \
    --to=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=julien.thierry@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=sumit.garg@linaro.org \
    --cc=suzuki.poulose@arm.com \
    --cc=swboyd@chromium.org \
    --cc=will.deacon@arm.com \
    --cc=will@kernel.org \
    /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).