On Wed, Oct 27, 2021, Sean Christopherson wrote: > And doling out the work to helpers also mostly eliminates the need to track the > inactive vs. active slot. There's still some slightly twisty logic, especially for > the MOVE case (which nobody uses, *sigh*). If we really want, even that mess can > be cleaned up by pre-allocating an extra memslot, but I don't think it's worth the > effort so long as things are well documented. Aha! I figured out how to do this in a way that reduces complexity and fixes the wart of "new" being an on-stack object, which has always bugged me but wasn't really fixable given the old/current memslots approach of duplicating the entire array. I belive it "needs" to be done as cleanup on top, i.e. what I've proposed here would still exist as an intermediate step, but the final result would be clean. Rather than reuse a single working slot, dynamically allocate "new" except in the DELETE case. That way a "working" slot isn't needed for CREATE or FLAGS_ONLY since they simply replace "old" (NULL for CREATE) with "new". It requires an extra allocation for MOVE, but (a) it's only a single memslot and (b) AFAIK no real VMM actually uses MOVE, and the benefit is that it significantly reduces the weirdness for the code as a whole. And even MOVE is cleaned up because it more clearly replace old and invalid_slot with new, as opposed to doing a weird dance where it uses the old slot as the "working" slot. Assuming my approach actually works, I really like the end result. I got waylaid yet again on other stuff, so I may not get a series posted today. *sigh*
