linux-kernel - Re: [PATCH v5 22/24] KVM: arm64: Add KVM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aTipeb2fAmUtSzzX@kernel.org>
Date: Tue, 9 Dec 2025 14:58:01 -0800
From: Oliver Upton <oupton@...nel.org>
To: Colton Lewis <coltonlewis@...gle.com>
Cc: kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
	Jonathan Corbet <corbet@....net>,
	Russell King <linux@...linux.org.uk>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Mingwei Zhang <mizhang@...gle.com>, Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Mark Rutland <mark.rutland@....com>, Shuah Khan <shuah@...nel.org>,
	Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-perf-users@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v5 22/24] KVM: arm64: Add KVM_CAP to partition the PMU

On Tue, Dec 09, 2025 at 08:51:19PM +0000, Colton Lewis wrote:
> +
> +7.245 KVM_CAP_ARM_PARTITION_PMU
> +-------------------------------------
> +

Why can't this be a vCPU attribute similar to the other vPMU controls?
Making the UAPI consistent will make it easier for userspace to reason
about it.

Better yet, we could make the UAPI such that userspace selects a PMU
implementation and the partitioned-ness of the PMU at the same time.

> @@ -132,6 +134,16 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
>  		}
>  		mutex_unlock(&kvm->lock);
>  		break;
> +	case KVM_CAP_ARM_PARTITION_PMU:
> +		if (kvm->created_vcpus) {
> +			r = -EBUSY;
> +		} else if (!kvm_pmu_partition_ready()) {
> +			r = -EPERM;
> +		} else {
> +			r = 0;
> +			kvm_pmu_partition_enable(kvm, cap->args[0]);
> +		}
> +		break;
>  	default:
>  		break;
>  	}
> @@ -388,6 +400,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  	case KVM_CAP_ARM_PMU_V3:
>  		r = kvm_supports_guest_pmuv3();
>  		break;
> +	case KVM_CAP_ARM_PARTITION_PMU:
> +		r = kvm_pmu_partition_ready();

"ready" is very confusing in this context, as KVM will never be ready to
support the feature on a system w/o the prerequisites.

Thanks,
Oliver