Re: [Xen-devel] [PATCH] xen/x86: Move microcode into its own directory

[Jan Beulich <jbeulich@xxxxxxxx>]

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. Likewise while IOMMU stuff may today be part of the
CPU package, it's still not core CPU functionality imo.

> 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.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel