On 27/02/2023 10:46 am, Jan Beulich wrote: > On 24.02.2023 22:33, Andrew Cooper wrote: >> But I think we want to change tact slightly at this point, so I'm not >> going to do any further tweaking on commit. >> >> Next, I think we want to rename asm/hvm/svm/svm.h to asm/hvm/svm.h, >> updating the non-SVM include paths as we go. Probably best to >> chain-include the other svm/hvm/svm/*.h headers temporarily, so we've >> only got one tree-wide cleanup of the external include paths. >> >> Quick tangent - I will be making all of that cpu_has_svm_* >> infrastructure disappear by moving it into the normal CPUID handling, >> but I've not had sufficient time to finish that yet. >> >> Next, hvm/svm/nestedsvm.h can merge straight into hvm/svm.h, and >> disappear (after my decoupling patch has gone in). > Why would you want to fold hvm/svm/nestedsvm.h into hvm/svm/svm.h? > The latter doesn't use anything from the former, does it?
It's about what else uses them. hvm_vcpu needs both svm_vcpu and nestedsvm, so both headers are always included in tandem. nestedsvm is literally just one struct now, and no subsystem ought to have multiple headers when one will do. The resulting "unified" svm.h will have very little in it, but everything in it (including nestedsvm) should be there. ~Andrew
