Re: [PATCH v17 10/20] KVM: arm64: coco: Disable Steal time accounting for coco guests

[Suzuki K Poulose]

Hi Fuad

On 09/09/2026 13:23, Fuad Tabba wrote:
> Hi Suzuki,
>
> On Wed, 9 Sept 2026 at 12:52, Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote:
> ...
>
> > > 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 that
> >
> >
> > But 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,
> /fuad
>
> > > steal-time exists but isn't permitted for a confidential VM, whereas
> > > -ENXIO reads as "no such feature".
> >
> > Cheers
> > Suzuki
> >
> >
> > > Cheers,
> > > /fuad
> > >
> > > >    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