[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/x86: Move microcode into its own directory
On 19/03/2020 09:59, Jan Beulich wrote: > On 19.03.2020 10:52, Andrew Cooper wrote: >> On 19/03/2020 09:21, Jan Beulich wrote: >>> On 18.03.2020 22:05, Andrew Cooper wrote: >>>> Split the existing asm/microcode.h in half, keeping the per-cpu cpu_sig >>>> available to external users, and moving everything else into private.h >>>> >>>> Take the opportunity to trim and clean up the include lists for all 3 >>>> source >>>> files, all of which include rather more than necessary. >>>> >>>> No functional change. >>>> >>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> >>> albeit preferably with ... >>> >>>> --- >>>> xen/arch/x86/Makefile | 4 +-- >>>> xen/arch/x86/microcode/Makefile | 3 ++ >>>> xen/arch/x86/{microcode_amd.c => microcode/amd.c} | 12 ++++---- >>>> xen/arch/x86/{microcode.c => microcode/core.c} | 15 +++------- >>>> .../x86/{microcode_intel.c => microcode/intel.c} | 9 ++---- >>>> .../microcode.h => arch/x86/microcode/private.h} | 19 ++++--------- >>> ... these going into xen/arch/x86/cpu/microcode/. Thoughts? >> TBH, I've always found the cpu/ directory redundant. Everything in >> arch/x86 is part of the CPU, and these days, even drivers/passthrough is >> part of the CPU. > I'm surprised of you saying so - certainly e.g. memory management > stuff also interfaces with the CPU, but is imo still helpful to be > separated. I can see an argument for things like domain.c not living in cpu/, but where do we draw the line? Should traps.c be considered cpu/ or not? What about FPU handling? > Likewise while IOMMU stuff may today be part of the > CPU package, it's still not core CPU functionality imo. Sure, for small systems, but considering it is effectively mandatory for a >255 cpu system, I'd no longer agree. After all, we know its not safe running an Intel system until you've turned on every thread's CR4.MCE, even if you don't actually want to use the thread. > >> I'm happy to put it wherever makes sense, so long as there is a clear >> understanding of why. > The boundaries are always going to be fuzzy, I think. As said, I'd > prefer the alternative place, but I'm not going to insist. All I'm looking for is some kind of clarity on what this boundary might be. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |