Message-ID: <a2f1b226-addf-673a-13c6-907021fc2bc2@loongson.cn>
Date: Fri, 5 Jul 2024 13:05:50 +0800
From: maobibo <maobibo@...ngson.cn>
To: Jiaxun Yang <jiaxun.yang@...goat.com>, Huacai Chen <chenhuacai@...nel.org>
Cc: Tianrui Zhao <zhaotianrui@...ngson.cn>, Xuerui Wang <kernel@...0n.name>,
 kvm@...r.kernel.org, loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/3] LoongArch: KVM: Add LBT feature detection function



On 2024/7/5 下午12:09, Jiaxun Yang wrote:
> 
> 
> 在2024年7月5日七月 上午11:46，maobibo写道：
>> On 2024/7/5 上午11:19, Jiaxun Yang wrote:
>>>
>>>
>>> 在2024年7月5日七月 上午9:21，maobibo写道：
>>> [...]
>>>>> for you.
>>>> On the other hand, can you list benefits or disadvantage of approaches
>>>> on different architecture?
>>>
>>> So the obvious benefit of scratch vCPU would be maintaining consistency and simpleness
>>> for UAPI.
>> I do not find the simpleness, for the same feature function, both VM
>> feature and CPU feature is define as follows.  Do you think it is for
>> simple :)
> 
> So they made a mistake here :-(
> 
> We don't even need vCPU flag, just probing CPUCFG bits is sufficient.
> 
> Note that in Arm's case, some CPU features have system dependencies, that's why
> they need to be entitled twice.
> 
> For us, we don't have such burden.
> 
> If Arm doesn't set a good example here, please check RISC-V's CONFIG reg on dealing
> ISA extensions. We don't even need such register because our CPUCFG can perfectly
> describe ISA status.
> 
>>
>> VM CAPBILITY:
>>       KVM_CAP_ARM_PTRAUTH_ADDRESS
>>       KVM_CAP_ARM_PTRAUTH_GENERIC
>>       KVM_CAP_ARM_EL1_32BIT
>>       KVM_CAP_ARM_PMU_V3
>>       KVM_CAP_ARM_SVE
>>       KVM_CAP_ARM_PSCI
>>       KVM_CAP_ARM_PSCI_0_2
>>
>> CPU:
>>       KVM_ARM_VCPU_POWER_OFF
>>       KVM_ARM_VCPU_EL1_32BIT
>>       KVM_ARM_VCPU_PSCI_0_2
>>       KVM_ARM_VCPU_PMU_V3
>>       KVM_ARM_VCPU_SVE
>>       KVM_ARM_VCPU_PTRAUTH_ADDRESS
>>       KVM_ARM_VCPU_PTRAUTH_GENERIC
>>       KVM_ARM_VCPU_HAS_EL2
>>
>> Also why scratch vcpu is created and tested on host cpu type rather than
>> other cpu type?  It wastes much time for host cpu type to detect capability.
> 
> To maximize supported features, on Arm there is KVM_ARM_VCPU_INIT ioctl.
> For us that's unnecessary, our kernel does not need to be aware of CPU type,
> only CPUCFG bits are necessary. RISC-V is following the same convention.
> 
>>>
>>> It can also maximum code reuse probabilities in other user space hypervisor projects.
>>>
>>> Also, it can benefit a potential asymmetrical system. I understand that it won't appear
>>> in near future, but we should always be prepared, especially in UAPI design.
>> If for potential asymmetrical system, however there is only one scratch
>> vcpu. is that right? how does only one scratch vcpu detect ASMP
>> capability, and it is not bind to physical cpu to detect ASMP capability.
>>
>> In generic big.little is HMP rather than ASMP, are you agree.
> 
> So I was talking about emulating asymmetrical guest. Each guest CPU should have
> it's own copy of properties. That's the lesson learnt.
For ASMP there may be problem if instruction set is different. However I 
think it is a little far from now with LoongArch.
> 
> [...]
> 
> Anyway I'm just trying to help out here, feel free to go ahead without taking my advice.
It is really nice to talk with you , hope more people taking part in 
community from my heart.
> 
> I've seen so many pitfalls on all other arches and I don't want them to repeat on LoongArch.
> But sometimes people only learn from mistakes.
Different arch has different history, LoongArch should take pitfalls 
again, it is normal rules just from my thoughts, only that it is new and 
has no much burden now.

Regards
Bibo Mao

Powered by blists - more mailing lists