On 06/01/2011 03:32 PM, Marcelo Tosatti wrote:
On Tue, May 31, 2011 at 10:03:26PM +0300, Avi Kivity wrote: > On 05/31/2011 09:48 PM, Marcelo Tosatti wrote: > >On Tue, May 31, 2011 at 09:05:35PM +0300, Avi Kivity wrote: > >> >> if (is_long_mode(vcpu)) { > >> >> if (!(cr4& X86_CR4_PAE)) > >> >> return 1; > >> > > >> >A new field in vcpu->arch.mmu.base_role for smep is required > >> >for shadow MMU (similar to nxe). > >> > >> I plan to add that with my cr0.wp=0 fixup (it's only needed there, right?) > > > >Sptes instantiated when cr4.smep = 0 should not be used when cr4.smep = > >1, so no (unlikely that guest kernel executes user=1 code anyway, but > >for consistency with other base_role flags). > > Why not? The sptes are interpreted exactly the same. > > sptes are interpreted differently when efer.nxe=1 - if bit 63 is > set, it will fault when nxe=0 and will not fault when nxe=1 (for > non-fetch accesses). So we can't share those sptes.A) CR4.SMEP = 0, spte instantiated via fetch fault of user pte. B) CR4.SMEP = 1, base_role unchanged. C) spte instantiated in A) used, but access should fault instead. Or if you have multiple CPUs with different settings.
Why would C) not fault? The spte has U=1, any fetch access from kernel mode with SMEP=1 will fault.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
