Message-ID: <704f58e2-f7ce-4d8d-b40d-52d773d13220@xen0n.name>
Date: Mon, 26 Feb 2024 16:07:16 +0800
From: WANG Xuerui <kernel@...0n.name>
To: maobibo <maobibo@...ngson.cn>, Huacai Chen <chenhuacai@...nel.org>
Cc: Tianrui Zhao <zhaotianrui@...ngson.cn>, Juergen Gross <jgross@...e.com>,
 Paolo Bonzini <pbonzini@...hat.com>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
 kvm@...r.kernel.org
Subject: Re: [PATCH v5 3/6] LoongArch: KVM: Add cpucfg area for kvm hypervisor

On 2/26/24 16:00, maobibo wrote:
> 
> 
> On 2024/2/26 下午1:25, WANG Xuerui wrote:
>> Hi,
>>
>> On 2/26/24 10:04, maobibo wrote:
>>> On 2024/2/24 下午5:13, Huacai Chen wrote:
>>>> Hi, Bibo,
>>>>
>>>> On Thu, Feb 22, 2024 at 11:28 AM Bibo Mao <maobibo@...ngson.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.
>>
>> While the CPUCFG instruction is universally available, it's also 
>> unprivileged, so any additional CPUCFG behavior also automatically 
>> becomes UAPI, which likely isn't what you expect. Hypervisor 
>> implementation details shouldn't be leaked to userland because it has 
>> no reason to care -- even though userland learns about the 
>> capabilities, it cannot actually access the resources, because 
>> relevant CSRs and/or instructions are privileged. Worse, the 
>> unnecessary exposure of information could be a problem security-wise.
> cpucfg is read-only and used to represent current hw cpu features,
> why do you think there is security issue?  Is there security issue about 
> cpucfg2 and cpucfg6 since it can be accessed in user space also?
> 
> PMU feature is defined in cpucfg6, PMU driver is written in kernel mode.

These CPUCFG leaves were added before existence of LoongArch were 
publicized, without community review. If early drafts of the manual were 
available to community reviewers, at least I would strongly NAK it.

>>
>> A possible way to preserve the unprivileged CPUCFG behavior would be 
>> acting differently based on guest CSR.CRMD.PLV: only returning data 
>> for the new configuration space when guest is not in PLV3. But this 
>> behavior isn't explicitly allowed nor disallowed in the LoongArch 
>> manuals, and is in my opinion unnecessarily complex.
>>
>> And regarding the lack of hypcall support from QEMU system mode 
>> emulation on TCG, I'd argue it's simply a matter of adding support in 
>> target/loongarch64. This would be attractive because it will enable 
>> easy development and testing of hypervisor software with QEMU -- both 
>> locally and in CI.
> Hypercall is part of hardware assisted virtualization LVZ, do you think
> only adding hypercall instruction withou LVZ is possible?

I cannot comment on the actual feasibility of doing so, because I don't 
have access to the LVZ manuals which *still* isn't publicly available. 
But from my intuition it should be a more-or-less trivial processor mode 
transition like with syscall -- whether that's indeed the case I can't 
(dis)prove.

>>> Extioi virtualization extension will be added later, cpucfg can be 
>>> used to get extioi features. It is unlikely that extioi driver 
>>> depends on PARA_VIRT macro if hypercall is used to get features.
>> And the EXTIOI feature too isn't something usable from unprivileged 
>> code, so I don't think it will affect the conclusions above.
> Sorry, I do not know what do you mean.

I was just saying this example provided no additional information at 
least for me -- while it's appreciated that you informed the community 
of your intended future use case, like what I stated in the first 
paragraph in my reply, it looked essentially the same because both PV 
and EXTIOI are privileged things.

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/

Powered by blists - more mailing lists