[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <192cfa2c-e54a-c7c1-30dd-7077e07e4af1@redhat.com>
Date: Mon, 1 Feb 2021 11:05:23 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Chenyi Qiang <chenyi.qiang@...el.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Xiaoyao Li <xiaoyao.li@...el.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/7] KVM: VMX: Expose IA32_PKRS MSR
On 01/02/21 10:53, Chenyi Qiang wrote:
>>>
>>
>> Is the guest expected to do a lot of reads/writes to the MSR (e.g. at
>> every context switch)?
>>
>> Even if this is the case, the MSR intercepts and the entry/exit
>> controls should only be done if CR4.PKS=1. If the guest does not use
>> PKS, KVM should behave as if these patches did not exist.
>>
>
> Hi Paolo,
>
> Per the MSR intercepts and entry/exit controls, IA32_PKRS access is
> independent of the CR4.PKS bit, it just depends on CPUID enumeration. If
> the guest doesn't set CR4.PKS but still has the CPUID capability,
> modifying on PKRS should be supported but has no effect. IIUC, we can
> not ignore these controls if CR4.PKS=0.
Understood, I wanted to avoid paying the price (if any) of loading PKRS
on vmentry and vmexit not just if CPUID.PKS=0, but also if CR4.PKS=0.
If CR4.PKS=0 it would be nicer to enable the MSR intercept and disable
the vmentry/vmexit controls; just run the guest with the host value of
IA32_PKRS.
Paolo
Powered by blists - more mailing lists