The low hanging fruit to mitigate Spectre would be to flush cache lines which were touched by false-speculation branch executions. Of course there'd be possible interaction with other, truly executed code hitting the same cache line.
Iff the microcode had instructions for cache line state manipulation it would be possible to emit µOps flushing cache lines touched in the other branch when merging with the true branch.
However this mitigation would only be possible if there were µOps for doing that and the instruction decoder was powerfull enough to do this kind of thing. Eventually we'll likely see silicon in which cache lines get additional status bits that keep track by which OOE engine the data was fetched and after branch merging flush all cache lines not matching the taken branch.
I'm not sure that'd help - as someone else observed in another thread, loading anything into a cache requires evicting something else, and that eviction can be measured. You could do something like maintaining a full duplicate of the cache and tracking deltas, but I feel like that's back in "rearchitect the CPU from the ground up" territory.
Iff the microcode had instructions for cache line state manipulation it would be possible to emit µOps flushing cache lines touched in the other branch when merging with the true branch.
However this mitigation would only be possible if there were µOps for doing that and the instruction decoder was powerfull enough to do this kind of thing. Eventually we'll likely see silicon in which cache lines get additional status bits that keep track by which OOE engine the data was fetched and after branch merging flush all cache lines not matching the taken branch.