From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753347AbdGJJRn (ORCPT ); Mon, 10 Jul 2017 05:17:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752711AbdGJJRl (ORCPT ); Mon, 10 Jul 2017 05:17:41 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4353D4E326 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pbonzini@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4353D4E326 Subject: Re: [PATCH 1/3 v2] KVM: vmx: Enable VMFUNCs To: David Hildenbrand , Bandan Das , kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org References: <20170706230323.29952-1-bsd@redhat.com> <20170706230323.29952-2-bsd@redhat.com> <71bb73d6-c64c-3fee-ea7d-4fa0f2d4682e@redhat.com> From: Paolo Bonzini Message-ID: <67f46756-7346-8280-7a7e-3f9898d18350@redhat.com> Date: Mon, 10 Jul 2017 11:17:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <71bb73d6-c64c-3fee-ea7d-4fa0f2d4682e@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 10 Jul 2017 09:17:41 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/07/2017 10:54, David Hildenbrand wrote: > >> /* >> * The exit handlers return 1 if the exit was handled fully and guest execution >> * may resume. Otherwise they set the kvm_run parameter to indicate what needs >> @@ -7790,6 +7806,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = { >> [EXIT_REASON_XSAVES] = handle_xsaves, >> [EXIT_REASON_XRSTORS] = handle_xrstors, >> [EXIT_REASON_PML_FULL] = handle_pml_full, >> + [EXIT_REASON_VMFUNC] = handle_vmfunc, >> [EXIT_REASON_PREEMPTION_TIMER] = handle_preemption_timer, >> }; >> >> @@ -8111,6 +8128,9 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu *vcpu) >> case EXIT_REASON_PML_FULL: >> /* We emulate PML support to L1. */ >> return false; >> + case EXIT_REASON_VMFUNC: >> + /* VM functions are emulated through L2->L0 vmexits. */ >> + return false; > > This would fit better into the second patch. It depends on how you reason about it. I put it here because: - until this patch, EXIT_REASON_VMFUNC should never be generated. We don't even know that it exists. - after this patch, it should still never be generated in nested scenarios. However, if it did because of a bug, we're in a better place to handle it than L1 (because as far as L1 knows, it should never be generated). Perhaps this is an argument in favor of changing the default case of nested_vmx_exit_handled from true to false. Paolo >> default: >> return true; >> } >> > > > Looks good to me. >