Hi -
On 2016-06-07 at 12:48 "Ronald G. Minnich" <[email protected]> wrote:
> diff --git a/kern/arch/x86/vmm/intel/vmx.c b/kern/arch/x86/vmm/intel/vmx.c
> index 5a93c5a..14e0588 100644
> --- a/kern/arch/x86/vmm/intel/vmx.c
> +++ b/kern/arch/x86/vmm/intel/vmx.c
> @@ -860,7 +860,11 @@ static int vmx_setup_initial_guest_state(struct proc *p,
> X86_CR0_MP | X86_CR0_ET | X86_CR0_NE);
> vmcs_writel(GUEST_CR3, rcr3());
> vmcs_writel(GUEST_CR4, cr4);
> - vmcs_writel(CR4_READ_SHADOW, cr4);
> + /* The only bits that matter in this shadow are those that are
> + * set in CR4_GUEST_HOST_MASK. TODO: do we need to separate
> + * the setting of this value from that of
> + * CR4_GUEST_HOST_MASK? */
> + vmcs_writel(CR4_READ_SHADOW, 0);
Regarding the TODO, perhaps we should merge vmx_setup_vmcs and
vmx_setup_initial_guest_state or something. Those are both only
called once, in succession, in create_guest_pcore().
> @@ -1096,7 +1100,17 @@ static void vmx_setup_vmcs(struct guest_pcore *gpc)
> vmcs_write32(VM_ENTRY_CONTROLS, vmcs_config.vmentry_ctrl);
>
> vmcs_writel(CR0_GUEST_HOST_MASK, 0); // ~0ul);
> - vmcs_writel(CR4_GUEST_HOST_MASK, 0); // ~0ul);
> +
> + /* Mask some bits in CR4 as host-owned by setting them in this
> + * VMCS entry. For example, for now, we mark the CR4_VMXE bit
> + * as host owned. Right now, when Linux boots, it wants to
> + * set CR4_VMXE to 0 at first, which is fine -- we do not want
> + * to think about nested virtualization yet. But if we don't
> + * mark this bit as host owned we get a VMEXIT. Marking
> + * CR4_VMXE as host owned means that the reads and writes go
> + * to the CR4_READ_SHADOW, and we've set the bit to 0
> + * there. */
> + vmcs_writel(CR4_GUEST_HOST_MASK, CR4_VMXE);
Is this comment true? This seems to say that the MASK redirects reads
and writes for the masked bits to the shadow register. The SDM says
this:
MOV to CR4. The MOV to CR4 instruction causes a VM exit unless
the value of its source operand matches, for the position of
each bit set in the CR4 guest/host mask, the corresponding bit
in the CR4 read shadow.
Which sounds like it means you get a VMEXIT if the write differs from
the shadow. So if Linux tried to write a 1, then we'd get a VMEXIT.
Also, the fact that the old mask code looked like this:
vmcs_writel(CR4_GUEST_HOST_MASK, 0); // ~0ul);
make it looks like the Dune/KVM code was setting it to all 1s, then we
changed it to all 0s. Not sure if there's something that needs to be
done there.
Barret
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
