From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9B5F354CF5F; Tue, 22 Sep 2026 22:04:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790114699; cv=none; b=fOhxDKVDOPDiXf7HmM8l5NqnI/8khlYwkhPETQoGK6OuG/VahtKTW0GHZp+BYWAqnkA/HCgzSK8JpL2vuBqqTSn63tkdygS/P0+aGKg9dS2HSiTjzDtsaxzHeDBrV0RR1jQPTLgpqnkB+gsugVZswPLckn7sQbyaBz4yVetSWfk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790114699; c=relaxed/simple; bh=Pme4KNcFZXJCIoYwtV2Ju4v44jpGiA6KmoFoYffHKlo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZEKWm1KzdlUfQRDukqgPr+EPjF+gIbVLk/pWlIV9W8wSICUNl51byBe8r1POdy0s+dJ6B8dRcE5x+eU7HQTr7uCF0Wk6DB1KJM5R2h9LwGPcveprxtkh4GzQfvv0iEZqArPJer2hmzWtlqqbNgWpHp5+uqXRNpW45jr+88lgICM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=iUzMrFNN; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="iUzMrFNN" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D76001576; Tue, 22 Sep 2026 15:04:43 -0700 (PDT) Received: from [10.57.9.113] (unknown [10.57.9.113]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A9ED3F632; Tue, 22 Sep 2026 15:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790114687; bh=Pme4KNcFZXJCIoYwtV2Ju4v44jpGiA6KmoFoYffHKlo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=iUzMrFNN2YDLQ/vBLkf5ziJp0MauZmc6HYaYVirUs9GjhN/W5+KiMaqyM/TSCVOSZ pNVGncyNZjg1NMBjqp+vvC8eTuIBydnjAOYGnLuEN87pTaXuSNq9gIUFCO49EjZzxL eUOm6uN1kKE8gf+vWa19FeEJ1R64dIb4XZcoflDY= Message-ID: Date: Tue, 22 Sep 2026 23:04:42 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v19 01/20] KVM: arm64: protected VM: Handle user writes to CNTVCT_EL0/CNTPCT_EL0 Content-Language: en-GB To: Jonathan Cameron Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, maz@kernel.org, will@kernel.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, steven.price@arm.com, aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com, joey.gouly@arm.com, tabba@google.com, yuzenghui@huawei.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, sdonthineni@nvidia.com, alpergun@google.com, fj0570is@fujitsu.com, WeiLin.Chang@arm.com, lpieralisi@kernel.org, enju.kohei@fujitsu.com References: <20260920212845.707-1-suzuki.poulose@arm.com> <20260920212845.707-2-suzuki.poulose@arm.com> <20260922122542.00006868@oss.qualcomm.com> From: Suzuki K Poulose In-Reply-To: <20260922122542.00006868@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 22/09/2026 20:25, Jonathan Cameron wrote: > On Sun, 20 Sep 2026 22:28:26 +0100 > Suzuki K Poulose wrote: > > Hi Suzuki, > >> Protected VMs doesn't allow setting offsets for virtual and phyiscal > > physical > >> counters, as the offset is always fixed to 0. The VM ioclt is filtered > > ioctl > >> out based on the cap. However we don't prevent the userspace from trying >> to write to the CNTVCT/CNTPCT registers. This would lead to KVM triggering >> a WARN() in timer_set_offset() as the vm_offset pointer is set to NULL. >> >> Fix this by always "fixing" the timer offsets to 0 and marking that the >> timer offset is set in the kvm->arch.flags at KVM init time for protected >> VMs. A userspace writing to the CNT*CT_EL0 would observe success, without >> any real effect. This was chosen over preventing the writes to these >> registers and returning -EPERM. > > Why? I don't mind the decision but telling us what was chosen is something > we can see in the code - patch description should give us the stuff we > can't see. > > One comment on the comment below. >> >> Reported by Sashiko >> >> Link: https://lore.kernel.org/all/20260908164641.416911F00A3A@smtp.kernel.org >> Fixes: f7d05ee84a6a ("KVM: arm64: Prevent host from managing timer offsets for protected VMs") >> Suggested-by: Marc Zyngier >> Signed-off-by: Suzuki K Poulose >> --- >> Changes since v18: >> - Retain NULL vm_offset for protected VMs to avoid host tampering with the >> offset. >> - Moved the flag setting into kvm_timer_init_vm(), where it should have been >> in the first place >> --- >> arch/arm64/kvm/arch_timer.c | 12 ++++++++++-- >> 1 file changed, 10 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c >> index 6ac3321f4c575..226cd5a495c8b 100644 >> --- a/arch/arm64/kvm/arch_timer.c >> +++ b/arch/arm64/kvm/arch_timer.c >> @@ -1110,8 +1110,7 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) >> timer_context_init(vcpu, i); >> >> /* Synchronize offsets across timers of a VM if not already provided */ >> - if (!vcpu_is_protected(vcpu) && >> - !test_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &vcpu->kvm->arch.flags)) { >> + if (!test_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &vcpu->kvm->arch.flags)) { >> timer_set_offset(vcpu_vtimer(vcpu), kvm_phys_timer_read()); >> timer_set_offset(vcpu_ptimer(vcpu), 0); >> } >> @@ -1133,6 +1132,15 @@ void kvm_timer_init_vm(struct kvm *kvm) >> */ >> for (int i = 0; i < NR_KVM_TIMERS; i++) >> kvm->arch.timer_data.ppi[i] = get_vgic_ppi(kvm, default_ppi[i]); >> + >> + /* >> + * Protected VMs don't allow any offset being set from userspace, >> + * either set via writes to the counters or using the dedicated > This sentence confused me. Second clause isn't obviously the ways that > are being blocked. Maybe shorten to: > > Protected VMs don't allow the offset to be set from userspace, > whether via writes to the counters or the dedicated ioctl. LLM suggests: * Protected VMs don't allow userspace to set counter offsets, * either via counter register writes or the dedicated ioctl. Have updated the comment. Cheers Suzuki > >> + * ioctl. Pretend the offset has already been set and rely on the >> + * default offset being 0. >> + */ >> + if (kvm_vm_is_protected(kvm)) >> + set_bit(KVM_ARCH_FLAG_VM_COUNTER_OFFSET, &kvm->arch.flags); >> } >> >> void kvm_timer_cpu_up(void) >