From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753634AbdGJJUw (ORCPT ); Mon, 10 Jul 2017 05:20:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50500 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753286AbdGJJUu (ORCPT ); Mon, 10 Jul 2017 05:20:50 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 539307F6A5 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=david@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 539307F6A5 Subject: Re: [PATCH 1/3 v2] KVM: vmx: Enable VMFUNCs To: Paolo Bonzini , 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> <67f46756-7346-8280-7a7e-3f9898d18350@redhat.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Mon, 10 Jul 2017 11:20:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <67f46756-7346-8280-7a7e-3f9898d18350@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.25]); Mon, 10 Jul 2017 09:20:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10.07.2017 11:17, Paolo Bonzini wrote: > > > 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. I remember having the same discussion before :) I still think the default should be changed (then we don't need nVMX hunks in VMX patches ;) ). Anyhow Reviewed-by: David Hildenbrand > > Paolo -- Thanks, David