lkml.org 
[lkml]   [2018]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86/kvm/nVMX: tweak shadow fields
From
Date
On 12/11/2018 15:39, Vitaly Kuznetsov wrote:
>> Is it worth having a set of VMCS shadowing bitmaps per-vCPU, in order
>> to make better use of this feature?
> Per CPU or not, to improve the feature we'll probably need some sort of
> an 'adaptive' algorithm picking which fields to shadow.

I agree, making it per-VCPU is not useful alone. The question is to
balance. The complexity and the number of fields that have to be copied
between the VMCSes.

If a vmexit type is rare, it makes sense not to shadow a field that
would be always defined by that vmexit type, rather than pay a fixed
price (even if it is loop overhead only) on all vmexits; this is the
case VMX_INSTRUCTION_INFO.

One thing that would make sense is to have separate shadow bitmaps for
32- and 64-bit L2. 32-bit L2 probably will need to shadow at least the
segment bases. But for 64-bit L2, the current set is small and nice.

There are still a few things that can be refined, but it's small things:

1) EXCEPTION_BITMAP which can go because everyone is probably using
eager FPU these days---and has always been if you have shadow VMCS;

2) CR0_READ_SHADOW/CR4_READ_SHADOW/GUEST_CR0/GUEST_CR4 were needed on
old KVM and would need to be tested on other hypervisors, but are
probably unnecessary;

3) I would be surprised if HOST_FS_BASE/HOST_GS_BASE are needed too,
though again you'd need testing on other hypervisors

Overall, I prefer simple code that optimizes the common case very well,
rather than complex code that tries to cover all bases...

Paolo

\
 
 \ /
  Last update: 2018-11-14 12:35    [W:0.054 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site