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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
