linux-kernel - Re: [PATCH v4 2/3] LoongArch: KVM: Add LBT feature detection function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <4cfc5292-6f1a-4409-b229-2433e18f012f@app.fastmail.com>
Date: Fri, 05 Jul 2024 12:09:49 +0800
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Bibo Mao" <maobibo@...ngson.cn>, "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

在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.

[...]

Anyway I'm just trying to help out here, feel free to go ahead without taking my advice.

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.

-- 
- Jiaxun