On Tue, Apr 30, 2019 at 10:34:52PM +0200, Paolo Bonzini wrote:
> On 30/04/19 19:36, Sean Christopherson wrote:
> > ... to prevent future code from using the unoptimized generic accessors
> > when hardcoding access to always-available GPRs.
>
> This cannot be done in general, because builtin_constant_p could be used
> through layers of inlining. For example you could have a function that
> takes an enum kvm_reg argument and _its_ caller passes a constant in
> there. Of course we may just say that we don't have such a case now (do
> we?) and so it's unlikely to happen in the future as well.
Another potential hiccup, and probably more likely, is that
the register save loops in enter_smm_save_state_{32,64} get unrolled by
the compiler.
My thought was (is?) that the only time KVM should ever use the
generic accessors is when the register is truly unknown, i.e. comes
from emulating an instruction with ModRM (or equivalent).
I thought about manually unrolling enter_smm_save_state_{32,64} so as
to avoid the caching logic, but that seemed like overkill at the time.
I didn't consider the compiler unrolling the loop and exploding. I'll
see if I can come up with anything clever for the SMM flow and expand
the changelog if I end up with a version that is "guaranteed" to not
run afould of compiler tricks.
P.S. Do you want me to send a patch with the cleanup parts that I unwisely
smushed into this patch? Or have you already taken care of that?
