On Tue, Jul 7, 2026 at 7:42 AM Sean Christopherson <[email protected]> wrote: > > On Mon, Jul 06, 2026, Jim Mattson wrote: > > On Mon, Jul 6, 2026 at 8:25 PM Jim Mattson <[email protected]> wrote: > > > > > > On Mon, Jul 6, 2026 at 8:21 PM Sean Christopherson <[email protected]> > > > wrote: > > > > > > > > On Tue, Jul 07, 2026, Tina Zhang wrote: > > > > > > > > > > > > > > > On 7/7/2026 9:32 AM, Jim Mattson wrote: > > > > > > On Mon, Jul 6, 2026 at 5:02 PM Tina Zhang > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > I will take another look for the next version and try to handle > > > > > > > the > > > > > > > remaining pieces properly, while also making sure we don't expose > > > > > > > stale > > > > > > > or incorrectly synthesized decode-assist state for emulated exits. > > > > > > > > > > > > Naples erratum 1096 seems to imply that the instruction bytes stored > > > > > > in the VMCB are not necessarily the same instruction bytes that were > > > > > > fetched and decoded to lead to the #PF/#NPF. Hence, in the case of > > > > > > emulation, it might be sufficient to read the instruction bytes > > > > > > quite > > > > > > late in nested_svm_vmexit(). That would certainly simplify the > > > > > > plumbing. > > > > > > > > The plumbing doesn't seem all that complex though. > > > > What about the case of a userspace-injected #PF while running L2, when > > L1 intercepts #PF? > > That can/will be handled by the fallback logic of reading the code stream > on-demand?
Could be, but I would prefer consistency.
