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
