Mingwei, On Tue, 27 Sep 2022 13:48:52 -0400, Mingwei Zhang <mizhang@xxxxxxxxxx> wrote: > > > > > Honestly, I'd refrain from such changes *unless* they enable something > > else. The current code is well understood by people hacking on it, and > > although I don't mind revamping it, it has to be for a good reason. > > > > I'd be much more receptive to such a change if it was a prefix to > > something that actually made a significant change. > > > > Thanks, > > > > M. > > > Hi Marc, > > Thanks for the feedback. I am not sure about the style of the KVM ARM > side. But in general I think mixing the generic code for ARM and > specific CPU errata handling is misleading. For instance, in this > case: > > + if ((esr & ESR_ELx_FSC_TYPE) == FSC_PERM) > + return false; > + > + if (cpus_have_final_cap(ARM64_WORKAROUND_834220)) > + return false; > > As shown it would be much cleaner to separate the two cases as the > former case is suggested in ARMv8 Spec D13.2.55. The latter case would > definitely come from a different source. I think we're talking at cross purposes. I don't object to the change per se. I simply question its value *in isolation*. One of the many things that makes the kernel hard to maintain is churn. Refactoring just for the sake of it *is* churn. In this case, cosmetic churn. But if you make this is part of something touching this area and improving things from a functional perspective, then I'll happily merge it. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
