[libvirt] [PATCH 0/4] cpu: modularize the CPU map data file

Jiri Denemark jdenemar at redhat.com
Tue Aug 14 14:39:53 UTC 2018


On Tue, Aug 14, 2018 at 08:21:40 -0400, John Ferlan wrote:
> 
> 
> On 08/14/2018 05:00 AM, Jiri Denemark wrote:
> > On Wed, Aug 01, 2018 at 18:02:28 +0100, Daniel P. Berrangé wrote:
> >> Currently we have a cpu_map.xml file that contains all the features and
> >> CPU models for all architectures in one place. I frequently find myself
> >> wondering about the differences between CPU models, but it is hard to
> >> compare them as the list of features is huge.
> >>
> >> With this patch series we end up with a large set of small files, one
> >> per named CPU model, along with one for the feature and vendor
> >> definitions
> >>
> >>    cpu_map_ppc64_POWER6.xml
> >>    cpu_map_ppc64_POWER7.xml
> >>    cpu_map_ppc64_POWER8.xml
> >>    cpu_map_ppc64_POWER9.xml
> >>    cpu_map_ppc64_POWERPC_e5500.xml
> >>    cpu_map_ppc64_POWERPC_e6500.xml
> >>    cpu_map_ppc64_vendors.xml
> >>    cpu_map_x86_486.xml
> >>    cpu_map_x86_athlon.xml
> > 
> > Could we make a cpu_map subdirectory and create the CPU definitions
> > there instead? For example
> > 
> >     src/cpu_map/ppc64_POWER6.xml
> >     src/cpu_map/x86_Broadwell-IBRS.xml
> 
> Hmm... The cpu_map or even some sort of 'arch' based subdirectory naming
> scheme could be useful... If it was src/cpu/cpu_map/ppc64/ and
> src/cpu/cpu_map/x86/, then for each .xml file in the @arch subdirectory
> type logic is possible, but that could possibly "miss" something that
> was 'previously available' from the parent cpu_map.xml file too since
> the include could have a directory or arch attribute rather than
> filename attribute. Is deleting a CPU a problem? Surely it'd make adding
> a new CPU easier since it would simply be adding a new file and no need
> to also add the include filename= to the main map.

I think we can still keep the <include filename="..."/> elements even
after moving the files into separate directory(ies). Adding a new file
is not that frequent to be worth optimizing by loading all files
automatically. And explicit includes makes possible issues with missing
files, wrong permissions, etc. easier to spot.

Jirka




More information about the libvir-list mailing list