> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S > > @@ -88,6 +88,12 @@ SYM_CODE_END(__kvm_hyp_init) > > * x0: struct kvm_nvhe_init_params PA > > */ > > SYM_CODE_START(___kvm_hyp_init) > > +alternative_cb kvm_patch_hcr_flags > > + mov_q x1, HCR_HOST_NVHE_FLAGS > > You really want to be careful here: the mov_q macro expands to 2, 3 or 4 > instructions, depending on the input data... > > It is also odd that you have both a static key and a patching alternative. > Why isn't "protected KVM" a capability that can be evaluated as a a non > patching alternative? In general, I'd like to reserve patching alternatives > to values that cannot be evaluated at compile time (VM offsets, for > example). Capability was my initial idea as well but it looked tied to CPU features. Looking at it again, you're right that there is precedent for setting them from kernel params. Alright, I'll change it and that will get rid of the custom patching. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
