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.
> >OK then, you'll fix that.
> >
>
> Sure. I'll post the patches as soon as this hits 'next'.
>
> --
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
>
> --
> 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
--
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
