Messages in this thread | | | Date | Tue, 27 Feb 2024 17:10:02 +0800 | Subject | Re: [PATCH v5 3/6] LoongArch: KVM: Add cpucfg area for kvm hypervisor | From | WANG Xuerui <> |
| |
On 2/27/24 11:14, maobibo wrote: > > > On 2024/2/27 上午4:02, Jiaxun Yang wrote: >> >> >> 在2024年2月26日二月 上午8:04,maobibo写道: >>> On 2024/2/26 下午2:12, Huacai Chen wrote: >>>> On Mon, Feb 26, 2024 at 10:04 AM maobibo <maobibo@loongson.cn> wrote: >>>>> >>>>> >>>>> >>>>> On 2024/2/24 下午5:13, Huacai Chen wrote: >>>>>> Hi, Bibo, >>>>>> >>>>>> On Thu, Feb 22, 2024 at 11:28 AM Bibo Mao <maobibo@loongson.cn> >>>>>> wrote: >>>>>>> >>>>>>> Instruction cpucfg can be used to get processor features. And there >>>>>>> is trap exception when it is executed in VM mode, and also it is >>>>>>> to provide cpu features to VM. On real hardware cpucfg area 0 - 20 >>>>>>> is used. Here one specified area 0x40000000 -- 0x400000ff is used >>>>>>> for KVM hypervisor to privide PV features, and the area can be >>>>>>> extended >>>>>>> for other hypervisors in future. This area will never be used for >>>>>>> real HW, it is only used by software. >>>>>> After reading and thinking, I find that the hypercall method which is >>>>>> used in our productive kernel is better than this cpucfg method. >>>>>> Because hypercall is more simple and straightforward, plus we don't >>>>>> worry about conflicting with the real hardware. >>>>> No, I do not think so. cpucfg is simper than hypercall, hypercall can >>>>> be in effect when system runs in guest mode. In some scenario like TCG >>>>> mode, hypercall is illegal intruction, however cpucfg can work. >>>> Nearly all architectures use hypercall except x86 for its historical >>> Only x86 support multiple hypervisors and there is multiple hypervisor >>> in x86 only. It is an advantage, not historical reason. >> >> I do believe that all those stuff should not be exposed to guest user >> space >> for security reasons. > Can you add PLV checking when cpucfg 0x40000000-0x400000FF is emulated? > if it is user mode return value is zero and it is kernel mode emulated > value will be returned. It can avoid information leaking.
I've suggested this approach in another reply [1], but I've rechecked the manual, and it turns out this behavior is not permitted by the current wording. See LoongArch Reference Manual v1.10, Volume 1, Section 2.2.10.5 "CPUCFG":
> CPUCFG 访问未定义的配置字将读回全 0 值。 > > Reads of undefined CPUCFG configuration words shall return all-zeroes.
This sentence mentions no distinction based on privilege modes, so it can only mean the behavior applies universally regardless of privilege modes.
I think if you want to make CPUCFG behavior PLV-dependent, you may have to ask the LoongArch spec editors, internally or in public, for a new spec revision.
(There are already multiple third-party LoongArch implementers as of late 2023, so any ISA-level change like this would best be coordinated, to minimize surprises.)
[1]: https://lore.kernel.org/loongarch/d8994f0f-d789-46d2-bc4d-f9b37fb396ff@xen0n.name/
-- WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
| |