# Re: [PATCH v5 3/6] LoongArch: KVM: Add cpucfg area for kvm hypervisor
    
    
    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@xxxxxxxxxxx> 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.
    

> `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?
    
    

> > `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.
    
    
    Regards
    Bibo Mao