On Thu, Jul 08, 2021, David Matlack wrote: > On Thu, Jul 08, 2021 at 09:13:38PM +0100, David Edmondson wrote: > > On Thursday, 2021-07-08 at 18:38:18 UTC, David Matlack wrote: > > > On Thu, Jul 08, 2021 at 03:17:40PM +0100, David Edmondson wrote: > > >> I can't cite an example of where this has definitively led in a > > >> direction that helped solve a problem, but we do sometimes see emulation > > >> failures reported in situations where we are not able to reproduce the > > >> failures on demand and the existing information provided at the time of > > >> failure is either insufficient or suspect. > > >> > > >> Given that, I'm left casting about for data that can be made available > > >> to assist in postmortem analysis of the failures. > > > > > > Understood, thanks for the context. My only concern would be that > > > userspace APIs are difficult to change once they exist. > > > > Agreed. > > > > > If it turns out knowing the exit reason does not help with debugging > > > emulation failures we'd still be stuck with exporting it on every > > > emulation failure. I can think of multiple cases where knowing why KVM emulated in the first place would be helpful, e.g. a failure on EPT misconfig (MMIO) exit could be a simple "drat, KVM doesn't handle SSE instructions", whereas a failure on a descriptor table exit (for UMIP emulation) would be a completely different mess.
