On 6/7/2023 11:40 AM, Huang, Kai wrote:
On Tue, 2023-06-06 at 17:18 +0800, Binbin Wu wrote:
Move CR4.LAM_SUP out of CR4_RESERVED_BITS and its reservation depends on vcpu
supporting LAM feature or not. Leave the bit intercepted to avoid vmread every
time when KVM fetches its value, with the expectation that guest won't toggle
the bit frequently.
KVM only needs to do vmread once to cache guest's CR4, and presumable vmread is
a lot cheaper than a VMEXIT. So I don't see the value of intercepting it if
there's no need to do.
Here is the discussion about the general rule of interception of CR4 bit.
Sean mentioned: "As a base
rule, KVM intercepts CR4 bits unless there's a reason not to, e.g. if
the CR4 bit
in question is written frequently by real guests and/or never consumed
by KVM."
https://lore.kernel.org/all/Y7xA53sLxCwzfvgD@xxxxxxxxxx/
And CR4.LAM_SUP value will be used to determin the LAM mode when apply
LAM masking in instruction emulations / VMExit handlers,
and if the bit is passed-through, it will be a vmread in these pathes.
But presumably I think we cannot allow guest to own this bit because KVM wants
to return a valid CR4 if LAM isn't exposed to guest? Otherwise guest can still
set this bit even LAM isn't exposed to guest.
Am I missing something?
Right, this is also a reason why the CR4.LAM_SUP bit should be intercepted.
Will update the justification.
I suppose this reason is enough for justification, will remove the
performance part in changelog.
Thanks.
If not, your justification of intercepting this bit isn't correct and needs
update.
