[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <561D169D.4050802@redhat.com>
Date: Tue, 13 Oct 2015 16:35:09 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Wanpeng Li <wanpeng.li@...mail.com>
Cc: Jan Kiszka <jan.kiszka@...mens.com>, Bandan Das <bsd@...hat.com>,
Wincy Van <fanwenyi0529@...il.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/5] KVM: nVMX: emulate the INVVPID instruction
On 08/10/2015 07:57, Wanpeng Li wrote:
> Add the INVVPID instruction emulation.
>
> Reviewed-by: Wincy Van <fanwenyi0529@...il.com>
> Signed-off-by: Wanpeng Li <wanpeng.li@...mail.com>
> ---
> arch/x86/include/asm/vmx.h | 3 +++
> arch/x86/kvm/vmx.c | 49 +++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> index 448b7ca..af5fdaf 100644
> --- a/arch/x86/include/asm/vmx.h
> +++ b/arch/x86/include/asm/vmx.h
> @@ -397,8 +397,10 @@ enum vmcs_field {
> #define IDENTITY_PAGETABLE_PRIVATE_MEMSLOT (KVM_USER_MEM_SLOTS + 2)
>
> #define VMX_NR_VPIDS (1 << 16)
> +#define VMX_VPID_EXTENT_INDIVIDUAL_ADDR 0
> #define VMX_VPID_EXTENT_SINGLE_CONTEXT 1
> #define VMX_VPID_EXTENT_ALL_CONTEXT 2
> +#define VMX_VPID_EXTENT_SHIFT 40
This is not used.
Comparing handle_invept with handle_invvpid, some differences are
apparent:
> static int handle_invvpid(struct kvm_vcpu *vcpu)
> {
> - kvm_queue_exception(vcpu, UD_VECTOR);
> + struct vcpu_vmx *vmx = to_vmx(vcpu);
> + u32 vmx_instruction_info;
> + unsigned long type;
> + gva_t gva;
> + struct x86_exception e;
> + int vpid;
> +
> + if (!(vmx->nested.nested_vmx_secondary_ctls_high &
> + SECONDARY_EXEC_ENABLE_VPID)) {
This lacks a check against VMX_VPID_INVVPID_BIT.
> + kvm_queue_exception(vcpu, UD_VECTOR);
> + return 1;
> + }
> +
> + if (!nested_vmx_check_permission(vcpu))
> + return 1;
> +
> + vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
> + type = kvm_register_readl(vcpu, (vmx_instruction_info >> 28) & 0xf);
This is missing the equivalent of this invept code:
types = (vmx->nested.nested_vmx_ept_caps >> VMX_EPT_EXTENT_SHIFT) & 6;
if (!(types & (1UL << type))) {
nested_vmx_failValid(vcpu,
VMXERR_INVALID_OPERAND_TO_INVEPT_INVVPID);
return 1;
}
> + /* according to the intel vmx instruction reference, the memory
> + * operand is read even if it isn't needed (e.g., for type==global)
> + */
> + if (get_vmx_mem_address(vcpu, vmcs_readl(EXIT_QUALIFICATION),
> + vmx_instruction_info, false, &gva))
> + return 1;
> + if (kvm_read_guest_virt(&vcpu->arch.emulate_ctxt, gva, &vpid,
> + sizeof(u32), &e)) {
> + kvm_inject_page_fault(vcpu, &e);
> + return 1;
> + }
> +
> + switch (type) {
> + case VMX_VPID_EXTENT_ALL_CONTEXT:
> + if (get_vmcs12(vcpu)->virtual_processor_id == 0) {
> + nested_vmx_failValid(vcpu,
> + VMXERR_INVALID_OPERAND_TO_INVEPT_INVVPID);
> + return 1;
> + }
> + vmx_flush_tlb(vcpu);
> + nested_vmx_succeed(vcpu);
> + break;
> + default:
> + /* Trap single context invalidation invvpid calls */
> + BUG_ON(1);
... which means that this BUG_ON(1) is guest triggerable.
Unit tests would have caught this... :)
Paolo
> + break;
> + }
> +
> + skip_emulated_instruction(vcpu);
> return 1;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists