On Wed, Apr 29, 2020 at 07:50:40AM -0700, Sean Christopherson wrote: > On Tue, Apr 28, 2020 at 04:16:16PM -0700, Jim Mattson wrote: > > On Tue, Apr 28, 2020 at 3:59 PM Sean Christopherson > > <sean.j.christopherson@xxxxxxxxx> wrote: > > > > > > On Tue, Apr 28, 2020 at 03:04:02PM -0700, Jim Mattson wrote: > > > > From the SDM, volume 3: > > > > > > > > • System-management interrupts (SMIs), INIT signals, and higher > > > > priority events take priority over MTF VM exits. > > > > > > > > I think this block needs to be moved up. > > > > > > Hrm. It definitely needs to be moved above the preemption timer, though I > > > can't find any public documentation about the preemption timer's priority. > > > Preemption timer is lower priority than MTF, ergo it's not in the same > > > class as SMI. > > > > > > Regarding SMI vs. MTF and #DB trap, to actually prioritize SMIs above MTF > > > and #DBs, we'd need to save/restore MTF and pending #DBs via SMRAM. I > > > think it makes sense to take the easy road and keep SMI after the traps, > > > with a comment to say it's technically wrong but not worth fixing. > > > > Pending debug exceptions should just go in the pending debug > > exceptions field. End of story and end of complications. I don't > > understand why kvm is so averse to using this field the way it was > > intended. > > Ah, it took my brain a bit to catch on. I assume you're suggesting calling > nested_vmx_updated_pending_dbg() so that the pending #DB naturally gets > propagated to/from vmcs12 on SMI/RSM? I think that should work. This works for L2, but not L1 :-( And L2 can't be fixed without first fixing L1 because inject_pending_event() also incorrectly prioritizes #DB over SMI. For L1, utilizing SMRAM to save/restore the pending #DB is likely the easiest solution as it avoids having to add new state for migration. I have everything coded up but it'll probably take a few weeks to test and get it sent out, need to focus on other stuff for a while.
