Hi Maxim, On 3/24/22 10:19 PM, Maxim Levitsky wrote:
I did some homework on this, and it looks mostly correct. However I do wonder if we need that separation of svm_direct_access_msrs and direct_access_x2apic_msrs. I understand the peformance wise, the direct_access_msrs will get longer otherwise (but we don't have to allow all x2apic msr range, but only known x2apic registers which aren't that many). One of the things that I see that*is* broken (at least in theory) is nesting. init_msrpm_offsets goes over direct_access_msrs and puts the offsets of corresponding bits in the hardware msr bitmap into the 'msrpm_offsets' Then on nested VM entry the nested_svm_vmrun_msrpm uses this list to merge the nested and host MSR bitmaps. Without x2apic msrs, this means that if L1 chooses to allow L2 to access its x2apic msrs it won't work. It is not something that L1 would do often but still allowed to overall. Honestly we need to write track the nested MSR bitmap to avoid updating it on each VM entry, then with this hot path eliminated, I don't think there are other places which update the msr interception often, and thus we could just put the x2apic msrs into the direct_access_msrs. Best regards, Maxim Levitsky
Good point. I will fix this. Suravee
