kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tao Cui <cui.tao@linux.dev>
To: Bibo Mao <maobibo@loongson.cn>, zhaotianrui@loongson.cn
Cc: cui.tao@linux.dev, chenhuacai@kernel.org, kernel@xen0n.name,
	kvm@vger.kernel.org, loongarch@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] LoongArch: KVM: Advertise already-supported capabilities
Date: Wed, 5 Aug 2026 13:18:53 +0800	[thread overview]
Message-ID: <2823cc0d-28ef-400f-8bfd-630ba42b6a1f@linux.dev> (raw)
In-Reply-To: <5bbfd376-d3e2-e62a-f07d-9a4ee0635780@loongson.cn>


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;
>>
> 


      reply	other threads:[~2026-08-05  5:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04  8:26 [PATCH] LoongArch: KVM: Advertise already-supported capabilities Tao Cui
2026-08-04  8:40 ` sashiko-bot
2026-08-05  2:36 ` Bibo Mao
2026-08-05  5:18   ` Tao Cui [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2823cc0d-28ef-400f-8bfd-630ba42b6a1f@linux.dev \
    --to=cui.tao@linux.dev \
    --cc=chenhuacai@kernel.org \
    --cc=kernel@xen0n.name \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=maobibo@loongson.cn \
    --cc=zhaotianrui@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).