From: Bandan Das <bsd@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor
Date: Mon, 10 Jul 2017 16:34:51 -0400 [thread overview]
Message-ID: <jpgd198kp3o.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <5fc42821-e544-ec6a-5e0f-4750da32da71@redhat.com> (David Hildenbrand's message of "Mon, 10 Jul 2017 22:09:43 +0200")
David Hildenbrand <david@redhat.com> writes:
>> - kvm_queue_exception(vcpu, UD_VECTOR);
>> + struct vcpu_vmx *vmx = to_vmx(vcpu);
>> + struct vmcs12 *vmcs12;
>> + u32 function = vcpu->arch.regs[VCPU_REGS_RAX];
>> +
>> + /*
>> + * VMFUNC is only supported for nested guests, but we always enable the
>> + * secondary control for simplicity; for non-nested mode, fake that we
>> + * didn't by injecting #UD.
>> + */
>> + if (!is_guest_mode(vcpu)) {
>> + kvm_queue_exception(vcpu, UD_VECTOR);
>> + return 1;
>> + }
>> +
>> + vmcs12 = get_vmcs12(vcpu);
>> + if ((vmcs12->vm_function_control & (1 << function)) == 0)
>> + goto fail;
>> + WARN(1, "VMCS12 VM function control should have been zero");
>
> Should this be a WARN_ONCE?
Even though this line gets removed in patch 3, I agree, it's a
good idea to use WARN_ONCE.
>> +
>> +fail:
>> + nested_vmx_vmexit(vcpu, vmx->exit_reason,
>> + vmcs_read32(VM_EXIT_INTR_INFO),
>> + vmcs_readl(EXIT_QUALIFICATION));
>> return 1;
>> }
>>
>> @@ -10053,7 +10092,8 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12,
>> exec_control &= ~(SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
>> SECONDARY_EXEC_RDTSCP |
>> SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
>> - SECONDARY_EXEC_APIC_REGISTER_VIRT);
>> + SECONDARY_EXEC_APIC_REGISTER_VIRT |
>> + SECONDARY_EXEC_ENABLE_VMFUNC);
>> if (nested_cpu_has(vmcs12,
>> CPU_BASED_ACTIVATE_SECONDARY_CONTROLS)) {
>> vmcs12_exec_ctrl = vmcs12->secondary_vm_exec_control &
>> @@ -10061,6 +10101,10 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12,
>> exec_control |= vmcs12_exec_ctrl;
>> }
>>
>> + /* All VMFUNCs are currently emulated through L0 vmexits. */
>> + if (exec_control & SECONDARY_EXEC_ENABLE_VMFUNC)
>> + vmcs_write64(VM_FUNCTION_CONTROL, 0);
>> +
>> if (exec_control & SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY) {
>> vmcs_write64(EOI_EXIT_BITMAP0,
>> vmcs12->eoi_exit_bitmap0);
>> @@ -10310,6 +10354,11 @@ static int check_vmentry_prereqs(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12)
>> vmx->nested.nested_vmx_entry_ctls_high))
>> return VMXERR_ENTRY_INVALID_CONTROL_FIELD;
>>
>> + if (nested_cpu_has_vmfunc(vmcs12) &&
>> + (vmcs12->vm_function_control &
>> + ~vmx->nested.nested_vmx_vmfunc_controls))
>
> I'd prefer the second part on one line, although it will violate 80
> chars. (these variable names really start to get too lengthy to be useful)
Yeah, I had to split it up for that.
Thank you for the quick review!
Bandan
>> + return VMXERR_ENTRY_INVALID_CONTROL_FIELD;
>> +
>> if (vmcs12->cr3_target_count > nested_cpu_vmx_misc_cr3_count(vcpu))
>> return VMXERR_ENTRY_INVALID_CONTROL_FIELD;
>>
>>
>
> Feel free to ignore my comments.
>
> Reviewed-by: David Hildenbrand <david@redhat.com>
next prev parent reply other threads:[~2017-07-10 20:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 19:53 [PATCH v3 0/3] Expose VMFUNC to the nested hypervisor Bandan Das
2017-07-10 19:53 ` [PATCH v3 1/3] KVM: vmx: Enable VMFUNCs Bandan Das
2017-07-10 19:53 ` [PATCH v3 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor Bandan Das
2017-07-10 20:09 ` David Hildenbrand
2017-07-10 20:34 ` Bandan Das [this message]
2017-07-10 19:53 ` [PATCH v3 3/3] KVM: nVMX: Emulate EPTP switching " Bandan Das
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jpgd198kp3o.fsf@linux.bootlegged.copy \
--to=bsd@redhat.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.