Date:   Wed,  8 Feb 2023 02:02:39 +0000
In-Reply-To: <20221109075413.1405803-1-yu.c.zhang@linux.intel.com>
Mime-Version: 1.0
References: <20221109075413.1405803-1-yu.c.zhang@linux.intel.com>
Message-ID: <167573583777.163276.8920768819160007143.b4-ty@google.com>
Subject: Re: [PATCH v2 0/2] Cleanup VMFUNC handling in KVM.
From:   Sean Christopherson <seanjc@google.com>
To:     Sean Christopherson <seanjc@google.com>, pbonzini@redhat.com,
        kvm@vger.kernel.org, Yu Zhang <yu.c.zhang@linux.intel.com>
Cc:     linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, 09 Nov 2022 15:54:11 +0800, Yu Zhang wrote:
> Since VMFUNC is not supported for non-nested guests, and executing VMFUNC
> can cause a #UD directly, if the =E2=80=9Cenable VM functions=E2=80=9D VM=
-execution control
> is 0, KVM can just disable it in VM-exectution control, instead of taking
> pains to trap it and emulate the #UD for L1 guests.
>=20
> Also, simplified the process of setting SECONDARY_EXEC_ENABLE_VMFUNC for
> nested VMX MSR configurations.
>=20
> [...]

After much waffling, applied to kvm-x86 vmx.  I ended up keeping the logic =
to
inject #UD on now-unexpected VMFUNC exits from L1, i.e. patch one does noth=
ing
more than clear the control bit.  I like the idea of clearing the control b=
it as
it more explicitly documents what's going on, but killing the VM on an unex=
pected
exit that KVM can gracefully handle seemed unnecessary.

Thanks!

[1/2] KVM: VMX: Do not trap VMFUNC instructions for L1 guests.
      https://github.com/kvm-x86/linux/commit/41acdd419735
[2/2] KVM: nVMX: Simplify the setting of SECONDARY_EXEC_ENABLE_VMFUNC for n=
ested.
      https://github.com/kvm-x86/linux/commit/496c917b0989

--
https://github.com/kvm-x86/linux/tree/next
https://github.com/kvm-x86/linux/tree/fixes