Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
From:   "Li, Xin3" <xin3.li@intel.com>
To:     "Gao, Chao" <chao.gao@intel.com>
CC:     "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "seanjc@google.com" <seanjc@google.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "kys@microsoft.com" <kys@microsoft.com>,
        "haiyangz@microsoft.com" <haiyangz@microsoft.com>,
        "wei.liu@kernel.org" <wei.liu@kernel.org>,
        "Cui, Dexuan" <decui@microsoft.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>,
        "vkuznets@redhat.com" <vkuznets@redhat.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>
Subject: RE: [PATCH v1 13/23] KVM: VMX: Handle VMX nested exception for FRED
Thread-Topic: [PATCH v1 13/23] KVM: VMX: Handle VMX nested exception for FRED
Thread-Index: AQHaEnYXOQlvFLhpWkG4lt/jksLCm7B5dqYAgAFC3tCAIVOmcIABoIUAgAAStHA=
Date:   Thu, 7 Dec 2023 10:09:46 +0000
Message-ID: <SA1PR11MB67342A44E1C2E17E127AA44AA88BA@SA1PR11MB6734.namprd11.prod.outlook.com>
References: <20231108183003.5981-1-xin3.li@intel.com>
 <20231108183003.5981-14-xin3.li@intel.com> <ZVMkVmBPVfaMjDTL@chao-email>
 <SA1PR11MB67348D3637C2BC6B107C5CCAA8B1A@SA1PR11MB6734.namprd11.prod.outlook.com>
 <SA1PR11MB6734EFF17E15C68AAD12A227A884A@SA1PR11MB6734.namprd11.prod.outlook.com>
 <ZXGFcuwwmkBlqq5s@chao-email>
In-Reply-To: <ZXGFcuwwmkBlqq5s@chao-email>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?d86xj6oXZKLCWQJ1rY4Ef4QFVMTleOLYe8sQEf9JiXIAO4/phBket9yjqNYO?=
 =?us-ascii?Q?oIyB2s1eIWYtOU4w1iVJWmR0AtDsSXfiNJZQL9a5MhOhHvPN0ZiuosoasF8t?=
 =?us-ascii?Q?ub0mYiO/NCKTUKgOlh8X0tiTg5UYb/EB/czMJkJwtaMV/+xK86wl6hbgBJnB?=
 =?us-ascii?Q?snAt6DrSg0XNwFUYDABdQ92bOdlyjTgvCGOo/MtdLf7hPz9+37LvZ8phD5gI?=
 =?us-ascii?Q?l2SzUtO78x33WLs43+NSvKCNT7PAnRJIU+ejSvZsbJpuUjsydU4gv27DWnIP?=
 =?us-ascii?Q?J4vztjH7zsNaqnl/foXyQb5gzPrxo263YMfZ/45WkPGNJ09bEIgAG/bkVNcn?=
 =?us-ascii?Q?VCRmG1kUnlVyaEslbHsaDluDnFDMBIce1gr6CUub3o+SpeDbAuu0HCAbYATP?=
 =?us-ascii?Q?Zb28dWRsTeq/XmRCCVQiMjkNroo4RAqYJGHrZ0BdM5UCZfJVF4ocH5Z/2McA?=
 =?us-ascii?Q?U69iH/oFbQnh5KqUroW/3wISbRIR56zY5rnQBSRn2kZuF5h/IEhluErQ1Rgf?=
 =?us-ascii?Q?mzdqOVQH2Npz3yhwq1o2y5YYIK34QuLvsqpcmiU+uIAxv77ZoWfGyM1ZezLn?=
 =?us-ascii?Q?8EIMmHI4Ppo1XYx4TL0SNyryLUdFkOA2VS8g/ycfGlwEPx+FLd/zYnbDCvtq?=
 =?us-ascii?Q?QT3lH6BpOixdXyGeRkbHP2EG5fdvAcW1aQAFZj/j9p3nTCxHZb+TgwAwqBL0?=
 =?us-ascii?Q?HEI54XivpJ2wYROgbAUMJVzRQsWarhNkuR84vG8wk2ET8mzKzVh7OYv4uJ3K?=
 =?us-ascii?Q?6UnwOPzSvz1wxkkJ38u8UU1PziWyGhX9CHw2Mtg7ens38NnPZUn1b5BEDHfE?=
 =?us-ascii?Q?E3IsaqIXD7dC4F3Hg1SUsCXkmrBPk7eyBxNQLr77+s2+8pOBfX4IoUmLO4s3?=
 =?us-ascii?Q?F7rpI2zwwNz3Vuom6Crl4+4MOnpXVuKz1gi+mNJdPthJ9GPFjDTL50k458yZ?=
 =?us-ascii?Q?eHPXXezLBO1Wtzhq7rFP5RQzn+o+YSJUKlNBseOKRxNZWOqHeqz2CPUIehWF?=
 =?us-ascii?Q?vDKDqpJuzEigxrzVir/NaXnXfkvN5bt1M7x8iQgAp7dYBO1lCnws7qeKfQ9w?=
 =?us-ascii?Q?OaMx0xoiQNxcSSNr28qL/VZI3mHd104IhsPCUjR1RkSb9HZ1/taaEXcKZjSK?=
 =?us-ascii?Q?GyKKZg2tyZIuyKb/TngxpgVGJ3KiP9LawBFz1y1WTQJQgFKF9td15zpZK+8X?=
 =?us-ascii?Q?5tTw7Z4q6RAE3fC2meFZiN13yl7NX8BHiGR0YYgqWfiWPEcnFDqMiDwMwz1p?=
 =?us-ascii?Q?alQqLzhVy7AkJGCWvVvORTxaCVgxeqInIfmMt8lwysyImhpoOlX4IVu1S8WV?=
 =?us-ascii?Q?65mj1llQEPfJYxbVwDyyKQxq2lHAheIU3NGj8ixyflK212wjHA6OU0gDeD+b?=
 =?us-ascii?Q?otNImXSv+i/ZkAQeXIb1CkUaZJnPz8N+VJA3p/E9IKkBZhLerqumIy7zU6py?=
 =?us-ascii?Q?JCSEs8PSgyUxm8K3igzDbpCiOdgTzn8w7wAF8tohEeJYZtc4siKXd5ytamhK?=
 =?us-ascii?Q?WDDjKaSxOtTmJ6UU+/9J+wFxtoeoSzWfciXyJiL3cpHVSGne+OrioNNE9PQK?=
 =?us-ascii?Q?uBC0SW5un0lr4edNZwg=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6734.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3f8bb752-20fd-46bd-c8a9-08dbf70ca3df
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2023 10:09:46.3842
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: blCkVG2ftWahGx/O41NyKoDFJfGO4SyyA8Bh3PgdFFy+IyE9tXsxkP3tPahye1GqIo24tXBHR2sSTVBJiGaB6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB7351
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 07 Dec 2023 02:10:08 -0800 (PST)

> >> > Exiting-event identification can also have bit 13 set, indicating a
> >> > nested exception encountered and caused VM-exit. when reinjecting th=
e
> >> > exception to guests, kvm needs to set the "nested" bit, right? I
> >> > suspect some changes to e.g., handle_exception_nmi() are needed.
> >>
> >> The current patch relies on kvm_multiple_exception() to do that.  But =
TBH, I'm
> >> not sure it can recognize all nested cases.  I probably should revisit=
 it.
> >
> >So the conclusion is that kvm_multiple_exception() is smart enough, and
> >a VMM doesn't have to check bit 13 of the Exiting-event identification.
> >
> >In FRED spec 5.0, section 9.2 - New VMX Feature: VMX Nested-Exception
> >Support, there is a statement at the end of Exiting-event identification=
:
> >
> >(The value of this bit is always identical to that of the valid bit of
> >the original-event identification field.)
> >
> >It means that even w/o VMX Nested-Exception support, a VMM already knows
> >if an exception is a nested exception encountered during delivery of
> >another event in an exception caused VM exit (exit reason 0).  This is
> >done in KVM through reading IDT_VECTORING_INFO_FIELD and calling
> >vmx_complete_interrupts() immediately after VM exits.
> >
> >vmx_complete_interrupts() simply queues the original exception if there =
is
> >one, and later the nested exception causing the VM exit could be cancell=
ed
> >if it is a shadow page fault.  However if the shadow page fault is cause=
d
> >by a guest page fault, KVM injects it as a nested exception to have gues=
t
> >fix its page table.
> >
> >I will add comments about this background in the next iteration.
>=20
> is it possible that the CPU encounters an exception and causes VM-exit du=
ring
> injecting an __interrupt__? in this case, no __exception__ will be (re-)q=
ueued
> by vmx_complete_interrupts().

I guess the following case is what you're suggesting:
KVM injects an external interrupt after shadow page tables are nuked.

vmx_complete_interrupts() are called after each VM exit to clear both
interrupt and exception queues, which means it always pushes the
deepest event if there is an original event.  In the above case, the
original event is the external interrupt KVM just tried to inject.