On 26/03/2020 12:24, Jan Beulich wrote: > On 25.03.2020 15:32, Andrew Cooper wrote: >> On 25/03/2020 14:16, Jan Beulich wrote: >>> On 23.03.2020 11:17, Andrew Cooper wrote: >>>> Currently, we allocate an 8 byte struct microcode_patch to point at a >>>> separately allocated struct microcode_intel. This is wasteful. >>> As indicated elsewhere I'm very much in favor of this, but I think it >>> wants doing in one of the earlier series, and then for AMD at the same >>> time. >> I've got some ideas for an AMD series given the replies I got, and will >> be able to do an equivalent microcode_amd => microcode_patch folding on >> that side. There is also further work to do, including unbreaking the >> OSVW logic (which has been totally clobbered by the start/end_update >> debacle). >> >> However, given that it taken this whole series to make the transition >> look safe on the Intel side, I really don't see a way of doing this >> "earlier". >> >> In particular, no amount of ifdefary suggested below can AFAICT make it >> safe to do this transform without having microcode_patch opaque to being >> with. >> >> Yes - there is a bit of churn, but I can't see a safe alternative. > Something like the one below (compile tested only, and not really > cleaned up in any way)? > > Jan
Thanks. I'll experiment with this approach. On a perhaps tangential note, what (if anything) are you plans regarding backport here? These defines are ok for a transitional period across a series (and probably means I'll need to get the AMD side ready to be committed at the same time), but I don't think we'd want them in the code for the longterm. I personally wasn't overly concerned about backports, but if you are, we should probably take this into consideration for the fixes. ~Andrew
