[PATCH] LoongArch: KVM: Advertise already-supported capabilities

[PATCH] LoongArch: KVM: Advertise already-supported capabilities

[Tao Cui]

Several LoongArch KVM features are fully implemented but were never
reported through their standard KVM_CHECK_EXTENSION probes, so userspace
cannot discover them and either ignores them or takes a slower path.
Advertise the ones that already work:

  - KVM_CAP_STEAL_TIME: steal time is fully implemented (host-side
    record plus guest paravirt), gated on kvm_pvtime_supported().

  - KVM_CAP_IRQFD_RESAMPLE: the resampler is generic code backed by the
    in-kernel irqchip; advertise it so userspace can use irqfd with
    resample for level-triggered interrupts.

  - KVM_CAP_VM_GPA_BITS: the guest physical address width is already
    computed as BIT(cpu_vabits), so return cpu_vabits directly.

  - KVM_CAP_VCPU_ATTRIBUTES: per-vCPU device-attribute ioctls are
    implemented (CPUCFG, PVTIME control); advertise the discovery cap.

This adds no new functionality; it only makes existing features
discoverable via the standard probe.

Signed-off-by: Tao Cui <cui.tao@linux.dev>
---
 arch/loongarch/kvm/vm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/loongarch/kvm/vm.c b/arch/loongarch/kvm/vm.c
index 1317c718f896..d7dd08d9be5b 100644
--- a/arch/loongarch/kvm/vm.c
+++ b/arch/loongarch/kvm/vm.c
@@ -120,8 +120,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_READONLY_MEM:
 	case KVM_CAP_IMMEDIATE_EXIT:
 	case KVM_CAP_IOEVENTFD:
+	case KVM_CAP_IRQFD_RESAMPLE:
 	case KVM_CAP_MP_STATE:
 	case KVM_CAP_SET_GUEST_DEBUG:
+	case KVM_CAP_VCPU_ATTRIBUTES:
 		r = 1;
 		break;
 	case KVM_CAP_NR_VCPUS:
@@ -136,6 +138,12 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_NR_MEMSLOTS:
 		r = KVM_USER_MEM_SLOTS;
 		break;
+	case KVM_CAP_STEAL_TIME:
+		r = kvm_pvtime_supported();
+		break;
+	case KVM_CAP_VM_GPA_BITS:
+		r = cpu_vabits;
+		break;
 	default:
 		r = 0;
 		break;

Re: [PATCH] LoongArch: KVM: Advertise already-supported capabilities

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Falsely advertising KVM_CAP_IRQFD_RESAMPLE without underlying architecture support leads to broken level-triggered interrupts (e.g., VFIO INTx pass-through).
--

--- Patch [1]: [PATCH] LoongArch: KVM: Advertise already-supported capabilities ---
commit 09ee78983007b60953a55e2354d4d1971a9bc4c7
Author: Tao Cui <cui.tao@linux.dev>
LoongArch: KVM: Advertise already-supported capabilities

This commit advertises several KVM capabilities for LoongArch to userspace
that are noted as already supported. It enables discovery for
KVM_CAP_STEAL_TIME, KVM_CAP_IRQFD_RESAMPLE, KVM_CAP_VM_GPA_BITS, and
KVM_CAP_VCPU_ATTRIBUTES.

> diff --git a/arch/loongarch/kvm/vm.c b/arch/loongarch/kvm/vm.c
> --- a/arch/loongarch/kvm/vm.c
> +++ b/arch/loongarch/kvm/vm.c
[ ... ]
> @@ -120,8 +120,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  	case KVM_CAP_READONLY_MEM:
>  	case KVM_CAP_IMMEDIATE_EXIT:
>  	case KVM_CAP_IOEVENTFD:
> +	case KVM_CAP_IRQFD_RESAMPLE:

[Severity: High]
Does the underlying architecture actually support IRQFD resamplers?

The commit message states the resampler is generic code backed by the
in-kernel irqchip. However, the generic irqfd resampler relies entirely
on the architecture's in-kernel irqchip explicitly calling
kvm_notify_acked_irq(), kvm_notify_acked_gsi(), or similar hooks when the
guest acknowledges the interrupt.

If the LoongArch irqchip implementations do not call any of these
notification hooks, the resampler will never trigger. Will this cause
physical interrupts to remain permanently masked after their first
injection, potentially hanging passed-through devices that rely on
level-triggered interrupts (such as VFIO INTx pass-through)?

>  	case KVM_CAP_MP_STATE:
>  	case KVM_CAP_SET_GUEST_DEBUG:
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804082604.178092-1-cui.tao@linux.dev?part=1

Re: [PATCH] LoongArch: KVM: Advertise already-supported capabilities

[Bibo Mao]

On 2026/8/4 下午4:26, Tao Cui wrote:
> Several LoongArch KVM features are fully implemented but were never
> reported through their standard KVM_CHECK_EXTENSION probes, so userspace
> cannot discover them and either ignores them or takes a slower path.
> Advertise the ones that already work:
> 
>    - KVM_CAP_STEAL_TIME: steal time is fully implemented (host-side
>      record plus guest paravirt), gated on kvm_pvtime_supported().
> 
>    - KVM_CAP_IRQFD_RESAMPLE: the resampler is generic code backed by the
>      in-kernel irqchip; advertise it so userspace can use irqfd with
>      resample for level-triggered interrupts.
> 
>    - KVM_CAP_VM_GPA_BITS: the guest physical address width is already
>      computed as BIT(cpu_vabits), so return cpu_vabits directly.
> 
>    - KVM_CAP_VCPU_ATTRIBUTES: per-vCPU device-attribute ioctls are
>      implemented (CPUCFG, PVTIME control); advertise the discovery cap.
> 
> This adds no new functionality; it only makes existing features
> discoverable via the standard probe.
> 
> Signed-off-by: Tao Cui <cui.tao@linux.dev>
> ---
>   arch/loongarch/kvm/vm.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/arch/loongarch/kvm/vm.c b/arch/loongarch/kvm/vm.c
> index 1317c718f896..d7dd08d9be5b 100644
> --- a/arch/loongarch/kvm/vm.c
> +++ b/arch/loongarch/kvm/vm.c
> @@ -120,8 +120,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>   	case KVM_CAP_READONLY_MEM:
>   	case KVM_CAP_IMMEDIATE_EXIT:
>   	case KVM_CAP_IOEVENTFD:
> +	case KVM_CAP_IRQFD_RESAMPLE:
By my understanding, KVM_CAP_IRQFD_RESAMPLE is used for VFIO intx 
irqline interrupt injection, is that true? now IOMMU and VFIO is not 
supported on LoongArch.

>   	case KVM_CAP_MP_STATE:
>   	case KVM_CAP_SET_GUEST_DEBUG:
> +	case KVM_CAP_VCPU_ATTRIBUTES:
this is ok.
>   		r = 1;
>   		break;
>   	case KVM_CAP_NR_VCPUS:
> @@ -136,6 +138,12 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>   	case KVM_CAP_NR_MEMSLOTS:
>   		r = KVM_USER_MEM_SLOTS;
>   		break;
> +	case KVM_CAP_STEAL_TIME:
> +		r = kvm_pvtime_supported();
> +		break;
this is ok.

> +	case KVM_CAP_VM_GPA_BITS:
> +		r = cpu_vabits;
Feature KVM_CAP_VM_GPA_BITS is also to control max supported GPA bit of 
VM, only only max supported PA bit on host. For example max PA bit is 48 
on host, it is ok to set GPA bit with 40 or 48, only if it is smaller 
than one on host.
If my understanding is correct, it is not supported on LoongArch now.

Regards
Bibo Mao
> +		break;
>   	default:
>   		r = 0;
>   		break;
> 

Re: [PATCH] LoongArch: KVM: Advertise already-supported capabilities

[Tao Cui]

Hi Bibo,
在 2026/8/5 10:36, Bibo Mao 写道:
> On 2026/8/4 下午4:26, Tao Cui wrote:
>> Several LoongArch KVM features are fully implemented but were never
>> reported through their standard KVM_CHECK_EXTENSION probes, so userspace
>> cannot discover them and either ignores them or takes a slower path.
>> Advertise the ones that already work:
>>
>>    - KVM_CAP_STEAL_TIME: steal time is fully implemented (host-side
>>      record plus guest paravirt), gated on kvm_pvtime_supported().
>>
>>    - KVM_CAP_IRQFD_RESAMPLE: the resampler is generic code backed by the
>>      in-kernel irqchip; advertise it so userspace can use irqfd with
>>      resample for level-triggered interrupts.
>>
>>    - KVM_CAP_VM_GPA_BITS: the guest physical address width is already
>>      computed as BIT(cpu_vabits), so return cpu_vabits directly.
>>
>>    - KVM_CAP_VCPU_ATTRIBUTES: per-vCPU device-attribute ioctls are
>>      implemented (CPUCFG, PVTIME control); advertise the discovery cap.
>>
>> This adds no new functionality; it only makes existing features
>> discoverable via the standard probe.
>>

Thanks for the careful review — you are right on both points.

I must admit I was a bit hasty here. I only verified that the probes
returned nonzero on a 3A6000 and didn't dig into what the capabilities
actually guarantee or who consumes them. The return values looked fine,
so the details you raised slipped through.

>> Signed-off-by: Tao Cui <cui.tao@linux.dev>
>> ---
>>   arch/loongarch/kvm/vm.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/loongarch/kvm/vm.c b/arch/loongarch/kvm/vm.c
>> index 1317c718f896..d7dd08d9be5b 100644
>> --- a/arch/loongarch/kvm/vm.c
>> +++ b/arch/loongarch/kvm/vm.c
>> @@ -120,8 +120,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>       case KVM_CAP_READONLY_MEM:
>>       case KVM_CAP_IMMEDIATE_EXIT:
>>       case KVM_CAP_IOEVENTFD:
>> +    case KVM_CAP_IRQFD_RESAMPLE:
> By my understanding, KVM_CAP_IRQFD_RESAMPLE is used for VFIO intx irqline interrupt injection, is that true? now IOMMU and VFIO is not supported on LoongArch.
> 
You're right. The real consumer is VFIO INTx level-interrupt passthrough,
and without IOMMU/VFIO there is no current LoongArch userspace that
would use irqfd + resample. I'll drop it for now and revisit it together
with VFIO/IOMMU support.
>>       case KVM_CAP_MP_STATE:
>>       case KVM_CAP_SET_GUEST_DEBUG:
>> +    case KVM_CAP_VCPU_ATTRIBUTES:
> this is ok.
>>           r = 1;
>>           break;
>>       case KVM_CAP_NR_VCPUS:
>> @@ -136,6 +138,12 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>       case KVM_CAP_NR_MEMSLOTS:
>>           r = KVM_USER_MEM_SLOTS;
>>           break;
>> +    case KVM_CAP_STEAL_TIME:
>> +        r = kvm_pvtime_supported();
>> +        break;
> this is ok.
> 
>> +    case KVM_CAP_VM_GPA_BITS:
>> +        r = cpu_vabits;
> Feature KVM_CAP_VM_GPA_BITS is also to control max supported GPA bit of VM, only only max supported PA bit on host. For example max PA bit is 48 on host, it is ok to set GPA bit with 40 or 48, only if it is smaller than one on host.
> If my understanding is correct, it is not supported on LoongArch now.
> 
Agreed, and thanks for catching this. I overlooked that the capability is
paired with a setter — on riscv, cap->args[0] lets userspace choose the
VM GPA width by selecting the stage-2 pgd levels. LoongArch's GPA width
is fixed at BIT(cpu_vabits) and that configurability is not implemented,
so advertising the cap would be misleading. Dropped.

v2 advertises only KVM_CAP_STEAL_TIME and KVM_CAP_VCPU_ATTRIBUTES (both
sanity-checked on 3A6000: they go 0 -> 1).

Thanks,
Tao
> Regards
> Bibo Mao
>> +        break;
>>       default:
>>           r = 0;
>>           break;
>>
>