On Tue, Sep 21, 2021, Ashish Kalra wrote: > This is simply a Hack, i don't think this is a good approach to take forward. But a clever hack ;-) > > Unless there's some fundamental technical hurdle I'm overlooking, if pv_ops can > > be configured early enough to handle this, then so can alternatives. > > Now, as i mentioned earlier, apply_alternatives() is only called boot > CPU identification has been done which is a lot of support code which > may be dependent on earlier setup_arch() code and then it does CPU > mitigtion selections before patching alternatives, again which may have > dependencies on previous code paths in setup_arch(), so i am not sure if > we can call apply_alternatives() earlier. apply_alternatives() is a generic helper that can work on any struct alt_instr array, e.g. KVM_HYPERCALL can put its alternative into a different section that's patched as soon as the VMM is identified. > Maybe for a guest kernel and virtualized boot enviroment, CPU > identification may not be as complicated as for a physical host, but > still it may have dependencies on earlier architecture specific boot > code. > > > Adding notify_page_enc_status_changed() may be necessary in the future, e.g. for TDX > > or SNP, but IMO that is orthogonal to adding a generic, 100% redundant helper. > > If we have to do this in the future and as Sean mentioned ealier that > vmcall needs to be fixed for TDX (as it will cause a #VE), then why not > add this abstraction right now ? I'm not objecting to adding a PV op, I'm objecting to kvm_sev_hypercall3(). If others disagree and feel it's the way forward, I certainly won't stand in the way, but IMO it's unnecessary code duplication.
