From: Marc Zyngier <maz@kernel.org>
To: Andrew Jones <drjones@redhat.com>
Cc: kvm@vger.kernel.org, kernel-team@android.com, graf@amazon.com,
Robin Murphy <robin.murphy@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/5] KVM: arm64: Refactor PMU attribute error handling
Date: Tue, 08 Sep 2020 11:09:31 +0100 [thread overview]
Message-ID: <79c1a29f8596c4b0c8af7dcfdc600f36@kernel.org> (raw)
In-Reply-To: <20200908095318.nzbnadvgcmxvt3xs@kamzik.brq.redhat.com>
Hi Andrew,
On 2020-09-08 10:53, Andrew Jones wrote:
> Hi Marc,
>
> On Tue, Sep 08, 2020 at 08:58:26AM +0100, Marc Zyngier wrote:
>> The PMU emulation error handling is pretty messy when dealing with
>> attributes. Let's refactor it so that we have less duplication,
>> and that it is easy to extend later on.
>>
>> A functional change is that kvm_arm_pmu_v3_init() used to return
>> -ENXIO when the PMU feature wasn't set. The error is now reported
>> as -ENODEV, matching the documentation.
>
> Hmm, I didn't think we could make changes like that, since some
> userspace
> somewhere may now depend on the buggy interface.
Well, this is the whole point of this patch: discussing whether
this change is acceptable or whether existing VMMs are relying
on such behaviour. We *could* leave it as is, but I thought I'd
bring it up!
> That said, I'm not really
> against the change, but maybe it should go as a separate patch.
Sure, why not.
>> -ENXIO is still returned
>> when the interrupt isn't properly configured.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>> arch/arm64/kvm/pmu-emul.c | 21 +++++++++------------
>> 1 file changed, 9 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
>> index f0d0312c0a55..93d797df42c6 100644
>> --- a/arch/arm64/kvm/pmu-emul.c
>> +++ b/arch/arm64/kvm/pmu-emul.c
>> @@ -735,15 +735,6 @@ int kvm_arm_pmu_v3_enable(struct kvm_vcpu *vcpu)
>>
>> static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
>> {
>> - if (!kvm_arm_support_pmu_v3())
>> - return -ENODEV;
>> -
>> - if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> - return -ENXIO;
>> -
>> - if (vcpu->arch.pmu.created)
>> - return -EBUSY;
>> -
>> if (irqchip_in_kernel(vcpu->kvm)) {
>> int ret;
>>
>> @@ -796,6 +787,15 @@ static bool pmu_irq_is_valid(struct kvm *kvm, int
>> irq)
>>
>> int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct
>> kvm_device_attr *attr)
>> {
>> + if (!kvm_arm_support_pmu_v3())
>> + return -ENODEV;
>> +
>> + if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> + return -ENODEV;
>
> nit: could combine these two if's w/ an ||
This was made to make the userspace visible change obvious to the
reviewer. Now that you have noticed it, I'm happy to merge these
two! ;-)
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Andrew Jones <drjones@redhat.com>
Cc: kvm@vger.kernel.org, kernel-team@android.com, graf@amazon.com,
Robin Murphy <robin.murphy@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/5] KVM: arm64: Refactor PMU attribute error handling
Date: Tue, 08 Sep 2020 11:09:31 +0100 [thread overview]
Message-ID: <79c1a29f8596c4b0c8af7dcfdc600f36@kernel.org> (raw)
In-Reply-To: <20200908095318.nzbnadvgcmxvt3xs@kamzik.brq.redhat.com>
Hi Andrew,
On 2020-09-08 10:53, Andrew Jones wrote:
> Hi Marc,
>
> On Tue, Sep 08, 2020 at 08:58:26AM +0100, Marc Zyngier wrote:
>> The PMU emulation error handling is pretty messy when dealing with
>> attributes. Let's refactor it so that we have less duplication,
>> and that it is easy to extend later on.
>>
>> A functional change is that kvm_arm_pmu_v3_init() used to return
>> -ENXIO when the PMU feature wasn't set. The error is now reported
>> as -ENODEV, matching the documentation.
>
> Hmm, I didn't think we could make changes like that, since some
> userspace
> somewhere may now depend on the buggy interface.
Well, this is the whole point of this patch: discussing whether
this change is acceptable or whether existing VMMs are relying
on such behaviour. We *could* leave it as is, but I thought I'd
bring it up!
> That said, I'm not really
> against the change, but maybe it should go as a separate patch.
Sure, why not.
>> -ENXIO is still returned
>> when the interrupt isn't properly configured.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>> arch/arm64/kvm/pmu-emul.c | 21 +++++++++------------
>> 1 file changed, 9 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
>> index f0d0312c0a55..93d797df42c6 100644
>> --- a/arch/arm64/kvm/pmu-emul.c
>> +++ b/arch/arm64/kvm/pmu-emul.c
>> @@ -735,15 +735,6 @@ int kvm_arm_pmu_v3_enable(struct kvm_vcpu *vcpu)
>>
>> static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
>> {
>> - if (!kvm_arm_support_pmu_v3())
>> - return -ENODEV;
>> -
>> - if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> - return -ENXIO;
>> -
>> - if (vcpu->arch.pmu.created)
>> - return -EBUSY;
>> -
>> if (irqchip_in_kernel(vcpu->kvm)) {
>> int ret;
>>
>> @@ -796,6 +787,15 @@ static bool pmu_irq_is_valid(struct kvm *kvm, int
>> irq)
>>
>> int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct
>> kvm_device_attr *attr)
>> {
>> + if (!kvm_arm_support_pmu_v3())
>> + return -ENODEV;
>> +
>> + if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> + return -ENODEV;
>
> nit: could combine these two if's w/ an ||
This was made to make the userspace visible change obvious to the
reviewer. Now that you have noticed it, I'm happy to merge these
two! ;-)
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Andrew Jones <drjones@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
kernel-team@android.com, graf@amazon.com,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v3 1/5] KVM: arm64: Refactor PMU attribute error handling
Date: Tue, 08 Sep 2020 11:09:31 +0100 [thread overview]
Message-ID: <79c1a29f8596c4b0c8af7dcfdc600f36@kernel.org> (raw)
In-Reply-To: <20200908095318.nzbnadvgcmxvt3xs@kamzik.brq.redhat.com>
Hi Andrew,
On 2020-09-08 10:53, Andrew Jones wrote:
> Hi Marc,
>
> On Tue, Sep 08, 2020 at 08:58:26AM +0100, Marc Zyngier wrote:
>> The PMU emulation error handling is pretty messy when dealing with
>> attributes. Let's refactor it so that we have less duplication,
>> and that it is easy to extend later on.
>>
>> A functional change is that kvm_arm_pmu_v3_init() used to return
>> -ENXIO when the PMU feature wasn't set. The error is now reported
>> as -ENODEV, matching the documentation.
>
> Hmm, I didn't think we could make changes like that, since some
> userspace
> somewhere may now depend on the buggy interface.
Well, this is the whole point of this patch: discussing whether
this change is acceptable or whether existing VMMs are relying
on such behaviour. We *could* leave it as is, but I thought I'd
bring it up!
> That said, I'm not really
> against the change, but maybe it should go as a separate patch.
Sure, why not.
>> -ENXIO is still returned
>> when the interrupt isn't properly configured.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>> arch/arm64/kvm/pmu-emul.c | 21 +++++++++------------
>> 1 file changed, 9 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
>> index f0d0312c0a55..93d797df42c6 100644
>> --- a/arch/arm64/kvm/pmu-emul.c
>> +++ b/arch/arm64/kvm/pmu-emul.c
>> @@ -735,15 +735,6 @@ int kvm_arm_pmu_v3_enable(struct kvm_vcpu *vcpu)
>>
>> static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
>> {
>> - if (!kvm_arm_support_pmu_v3())
>> - return -ENODEV;
>> -
>> - if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> - return -ENXIO;
>> -
>> - if (vcpu->arch.pmu.created)
>> - return -EBUSY;
>> -
>> if (irqchip_in_kernel(vcpu->kvm)) {
>> int ret;
>>
>> @@ -796,6 +787,15 @@ static bool pmu_irq_is_valid(struct kvm *kvm, int
>> irq)
>>
>> int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct
>> kvm_device_attr *attr)
>> {
>> + if (!kvm_arm_support_pmu_v3())
>> + return -ENODEV;
>> +
>> + if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> + return -ENODEV;
>
> nit: could combine these two if's w/ an ||
This was made to make the userspace visible change obvious to the
reviewer. Now that you have noticed it, I'm happy to merge these
two! ;-)
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-09-08 10:09 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 7:58 [PATCH v3 0/5] KVM: arm64: Filtering PMU events Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 7:58 ` [PATCH v3 1/5] KVM: arm64: Refactor PMU attribute error handling Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 9:53 ` Andrew Jones
2020-09-08 9:53 ` Andrew Jones
2020-09-08 9:53 ` Andrew Jones
2020-09-08 10:09 ` Marc Zyngier [this message]
2020-09-08 10:09 ` Marc Zyngier
2020-09-08 10:09 ` Marc Zyngier
2020-09-08 7:58 ` [PATCH v3 2/5] KVM: arm64: Use event mask matching architecture revision Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 10:02 ` Andrew Jones
2020-09-08 10:02 ` Andrew Jones
2020-09-08 10:02 ` Andrew Jones
2020-09-09 9:38 ` Auger Eric
2020-09-09 9:38 ` Auger Eric
2020-09-09 9:38 ` Auger Eric
2020-09-09 9:54 ` Marc Zyngier
2020-09-09 9:54 ` Marc Zyngier
2020-09-09 9:54 ` Marc Zyngier
2020-09-09 9:58 ` Auger Eric
2020-09-09 9:58 ` Auger Eric
2020-09-09 9:58 ` Auger Eric
2020-09-08 7:58 ` [PATCH v3 3/5] KVM: arm64: Add PMU event filtering infrastructure Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 10:15 ` Andrew Jones
2020-09-08 10:15 ` Andrew Jones
2020-09-08 10:15 ` Andrew Jones
2020-09-09 17:14 ` Auger Eric
2020-09-09 17:14 ` Auger Eric
2020-09-09 17:14 ` Auger Eric
2020-09-08 7:58 ` [PATCH v3 4/5] KVM: arm64: Mask out filtered events in PCMEID{0, 1}_EL1 Marc Zyngier
2020-09-08 7:58 ` [PATCH v3 4/5] KVM: arm64: Mask out filtered events in PCMEID{0,1}_EL1 Marc Zyngier
2020-09-08 7:58 ` [PATCH v3 4/5] KVM: arm64: Mask out filtered events in PCMEID{0, 1}_EL1 Marc Zyngier
2020-09-09 17:43 ` [PATCH v3 4/5] KVM: arm64: Mask out filtered events in PCMEID{0,1}_EL1 Auger Eric
2020-09-09 17:43 ` Auger Eric
2020-09-09 17:43 ` Auger Eric
2020-09-09 17:50 ` Marc Zyngier
2020-09-09 17:50 ` Marc Zyngier
2020-09-09 17:50 ` Marc Zyngier
2020-09-09 18:07 ` Auger Eric
2020-09-09 18:07 ` Auger Eric
2020-09-09 18:07 ` Auger Eric
2020-09-08 7:58 ` [PATCH v3 5/5] KVM: arm64: Document PMU filtering API Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 7:58 ` Marc Zyngier
2020-09-08 10:28 ` Andrew Jones
2020-09-08 10:28 ` Andrew Jones
2020-09-08 10:28 ` Andrew Jones
2020-09-09 17:47 ` Auger Eric
2020-09-09 17:47 ` Auger Eric
2020-09-09 17:47 ` Auger Eric
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=79c1a29f8596c4b0c8af7dcfdc600f36@kernel.org \
--to=maz@kernel.org \
--cc=drjones@redhat.com \
--cc=graf@amazon.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=robin.murphy@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 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.