Re: [PATCH v17 10/20] KVM: arm64: coco: Disable Steal time accounting for coco guests
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Date: 2026-09-10 10:27:58
Also in:
kvm, kvmarm, linux-arm-kernel, lkml
Hi Fuad On 09/09/2026 13:23, Fuad Tabba wrote:
Hi Suzuki, On Wed, 9 Sept 2026 at 12:52, Suzuki K Poulose [off-list ref] wrote: ...quoted
quoted
I think it would be better to leave KVM_CAP_STEAL_TIME reported and instead reject the configuration for these VMs, returning -EPERM from the KVM_ARM_VCPU_PVTIME_CTRL attr. A capability query should report what the kernel supports, not whether a given VM may use it; gating it per-VM here is also inconsistent, since the !kvm clause leaves the system-fd cap at 1 while the VM-fd cap reads 0. And -EPERM says thatBut isn't that we want from a VMM perspective ? i.e., enable PVTIME if it is supported for the given VM (type). Rather than PVTIME is supported by the KVM, so I can go enable it by default. But, we endup getting a failure while we enable it. I encountered this with kvmtool, where CAP_STEAL_TIME is reported true and even the HAS_DEVICE_ATTR goes through fine, but SET_DEVICE_ATTR seemed to fail. Isn't it better to allow the VM to decide if the capability is supported for the given VM type, like we are doing for other capabilities ?You're right, per-VM capability reporting. My wires got crossed from the pKVM series and the kvmtool fixes. However, I'd still return -EPERM rather than -ENXIO from the attribute. The capability exists,
Just to make sure I understand the picture: For coco VMs: - check extension on coco KVM, KVM_CAP_STEAL_TIME => 0 And a follow up DEVICE_HAS_ATTR => -EPERM ? But we tell the VMM, look you don't have the capabilit on this VM. But if you try to set the attribute isn't it more appropriate to say: -ENXIO - No you don't have that feature on this VM (-ENXIO) rather than -EPERM - No, I won't let you do that. Remember we are doing only in the "VM" context. It is a minor nit but I wanted to make sure we understand what we are thinking. Cheers Suzuki
it's just not permitted for a confidential VM, and -EPERM says exactly that, whereas -ENXIO reads as "no such feature". Cheers, /fuadquoted
quoted
steal-time exists but isn't permitted for a confidential VM, whereas -ENXIO reads as "no such feature".Cheers Suzukiquoted
Cheers, /fuadquoted
int kvm_arm_pvtime_set_attr(struct kvm_vcpu *vcpu,@@ -81,7 +81,7 @@ int kvm_arm_pvtime_set_attr(struct kvm_vcpu *vcpu, int ret = 0; int idx; - if (!kvm_arm_pvtime_supported() || + if (!kvm_arm_pvtime_supported(kvm) || attr->attr != KVM_ARM_VCPU_PVTIME_IPA) return -ENXIO;@@ -110,7 +110,7 @@ int kvm_arm_pvtime_get_attr(struct kvm_vcpu *vcpu, u64 __user *user = (u64 __user *)attr->addr; u64 ipa; - if (!kvm_arm_pvtime_supported() || + if (!kvm_arm_pvtime_supported(vcpu->kvm) || attr->attr != KVM_ARM_VCPU_PVTIME_IPA) return -ENXIO;@@ -126,7 +126,7 @@ int kvm_arm_pvtime_has_attr(struct kvm_vcpu *vcpu, { switch (attr->attr) { case KVM_ARM_VCPU_PVTIME_IPA: - if (kvm_arm_pvtime_supported()) + if (kvm_arm_pvtime_supported(vcpu->kvm)) return 0; } return -ENXIO; --2.43.0