[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;


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(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

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. 
>>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

>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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.