On Tue, Jul 7, 2026 at 8:47 AM Sean Christopherson <[email protected]> wrote: > > On Tue, Jul 07, 2026, Jim Mattson wrote: > > 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. > > Not sure I follow. Consistency with what? If userspace injects a #PF in > response > to an exit from emulator proper, the emulator context will still be valid. > If the > #PF is injected for something like X86_WRMSR, X86_RDMSR, or MEMORY_FAULT, KVM > will > fetch the bytes on-demand, same as it would if KVM itself synthesized a #PF > that > didn't originate in hardware.
I was thinking about pre- and post- suspend/resume. But I didn't think it through. Any KVM exit where userspace can synthesize a #PF is one where the VPCU can't be suspended. So, I retract my concern.
