[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [Patch] Enable SMEP CPU feature support for XEN itself
>>mmu_cr4_features |= X86_CR4_SMEP; >Why? I replied in another reply to you, but just repeat here: But it is a good idea to set X86_CR4_SMEP in mmu_cr4_features when SMEP Is available. thus 1) for PV, we can make patch like pv_guest_cr4_to_real_cr4 #define pv_guest_cr4_to_real_cr4(v) \ (((v)->arch.pv_vcpu.ctrlreg[4] \ | (mmu_cr4_features & (X86_CR4_PGE | X86_CR4_PSE | X86_CR4_SMEP)) \ | ((v)->domain->arch.vtsc ? X86_CR4_TSD : 0) \ | ((xsave_enabled(v))? X86_CR4_OSXSAVE : 0)) \ & ~X86_CR4_DE) when set cr4. 2) For HVM, we don't need to explicitly add SMEP when write to HOST_CR4. >>set_in_cr4(0); >set_in_cr4(X86_CR4_SMEP) does exactly what you need. Yes, but once we have X86_CR4_SMEP in mmu_cr4_features, set_in_cr4(0) does the same thing except looks ugly. >} else >>setup_clear_cpu_cap(X86_FEATURE_SMEP); This needs to be done on APs too. Thus I think we still need define setup_smep as __cpuinit. >>At the beginning we did accumulate the user bit into a separate variable. >>However >>SMEP faults hardly happen while we keep accumulating user bit no matter it's a >>spurious fault or not, and even spurious faults are rare I guess. >Remember that we're going through this function for almost every page >fault happening in Xen, and also for the majority of those originating >from certain pv guests (when they have suppress_spurious_page_faults >set). >Also, my comment was to a large part aiming at better legibility of the >code you add. Yes, for legibility we may change it back. Thanks! -Xin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |