On 16/02/21 17:25, Joerg Roedel wrote:
On Tue, Feb 16, 2021 at 04:59:52PM +0100, Paolo Bonzini wrote:- the inner handler does nothing but telling the outer handler to rerun. The way it does it is certainly not pretty, because it has to work at any instruction boundary, but at its heart it's basically a do{}while loop.That only works if processing of all inner #VE can be deferred, which is not the case for instruction emulation #VEs like MSR accesses, io-port or MMIO accesses.
No doubt about that, but that's unrelated to ISTs. ISTs are ugly and the ugliness is a symptom of the problem; but not part of the problem. NMIs are as usual the most worrisome since you can get those from random perf events.
We should minimize the number of #VEs that we get, as they are very slow. Could almost everything that can invoke a #VE go through pvops and be turned into a TDCALL? And if so the same should be true for SEV-ES #VC as well.
I guess those could all be replaced direct TDCALLs, but the question remains whether this is possible with MSR accesses, means that the list of MSRs which will cause #VEs is statically defined and doesn't change between hypervisors. All in all this sounds hard to maintain and easy to break by unrelated changes.
I would expect that all MSRs except for a handful (SPEC_CTRL/PRED_CMD, the FS/GS/kernelGS bases, anything else?) would be redirect to TDCALL.
Paolo
