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
