Received-SPF: pass (google.com: domain of linux-kernel+bounces-100548-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 12 Mar 2024 09:54:39 -0700
In-Reply-To: <6d0f2392-bc93-445d-9169-65221fb55329@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240227232100.478238-1-pbonzini@redhat.com> <20240227232100.478238-8-pbonzini@redhat.com>
 <6d0f2392-bc93-445d-9169-65221fb55329@intel.com>
Message-ID: <ZfCIz8JIziuvl8Xp@google.com>
Subject: Re: [PATCH 07/21] KVM: VMX: Introduce test mode related to EPT
 violation VE
From: Sean Christopherson <seanjc@google.com>
To: Kai Huang <kai.huang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, 
	michael.roth@amd.com, isaku.yamahata@intel.com, thomas.lendacky@amd.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 12, 2024, Kai Huang wrote:
> On 28/02/2024 12:20 pm, Paolo Bonzini wrote:
> > From: Isaku Yamahata <isaku.yamahata@intel.com>
> >=20
> > To support TDX, KVM is enhanced to operate with #VE.  For TDX, KVM uses=
 the
> > suppress #VE bit in EPT entries selectively, in order to be able to tra=
p
> > non-present conditions.  However, #VE isn't used for VMX and it's a bug
> > if it happens.  To be defensive and test that VMX case isn't broken
> > introduce an option ept_violation_ve_test and when it's set, BUG the vm=
.
>=20
> I am wondering from HW's point of view, is it OK for the kernel to
> explicitly send #VE IPI, in which case, IIUC, the guest can legally get t=
he
> #VE w/o being a TDX guest?

Ooh, fun.  Short answer: there's nothing to worry about here.

Legally, no.  Vectors 0-31 are reserved.  However, I do _think_ the guest c=
ould
technically send IPIs on vectors 16-31, as the local APIC doesn't outright =
reject
such vectors.  But such software would be in clear violation of the SDM.

  11.5.2 Valid Interrupt Vectors
 =20
  The Intel 64 and IA-32 architectures define 256 vector numbers, ranging f=
rom
  0 through 255 (see Section 6.2, =E2=80=9CException and Interrupt Vectors=
=E2=80=9D). Local and
  I/O APICs support 240 of these vectors (in the range of 16 to 255) as val=
id
  interrupts.
 =20
  When an interrupt vector in the range of 0 to 15 is sent or received thro=
ugh
  the local APIC, the APIC indicates an illegal vector in its Error Status
  Register (see Section 11.5.3, =E2=80=9CError Handling=E2=80=9D). The Inte=
l 64 and IA-32
  architectures reserve vectors 16 through 31 for predefined interrupts,
  exceptions, and Intel-reserved encodings (see Table 6-1). However, the lo=
cal
  APIC does not treat vectors in this range as illegal.

  When an illegal vector value (0 to 15) is written to an LVT entry and the=
 delivery
  mode is Fixed (bits 8-11 equal 0), the APIC may signal an illegal vector =
error,
  without regard to whether the mask bit is set or whether an interrupt is =
actually
  seen on the input.

where Table 6-1 defines the various exceptions, including #VE, and for vect=
ors
22-31 says "Intel reserved. Do not use."  Vectors 32-255 are explicitly des=
cribed
as "User Defined (Non-reserved) Interrupts" that can be generated via "Exte=
rnal
interrupt or INT n instruction."

However, INTn is far more interesting than IPIs, as INTn can definitely gen=
erate
interrupts for vectors 0-31, and the legality of software generating such i=
nterrupts
is questionable.  E.g. KVM used to "forward" NMI VM-Exits to the kernel by =
doing
INTn with vector 2.

Key word "interrupts"!  IPIs are hardware interrupts, and INTn generates so=
ftware
interrupts, neither of which are subject to exception bitmap interception:

  Exceptions (faults, traps, and aborts) cause VM exits based on the except=
ion
  bitmap (see Section 25.6.3). If an exception occurs, its vector (in the r=
ange
  0=E2=80=9331) is used to select a bit in the exception bitmap. If the bit=
 is 1, a VM
  exit occurs; if the bit is 0, the exception is delivered normally through=
 the
  guest IDT. This use of the exception bitmap applies also to exceptions ge=
nerated
  by the instructions INT1, INT3, INTO, BOUND, UD0, UD1, and UD2.

with a footnote that further says:

  INT1 and INT3 refer to the instructions with opcodes F1 and CC, respectiv=
ely,
  and not to INT n with value 1 or 3 for n.

So while a misbehaving guest could generate a software interrupt on vector =
20,
it would not be a true #VE, i.e. not an exception, and thus would not gener=
ate
an EXCEPTION_NMI VM-Exit.  I.e. the KVM_BUG_ON() can't be triggered by the =
guest
(assuming hardware isn't broken).