On Wed, Oct 07, 2020 at 12:29:42 +0200, Jiri Denemark wrote: > On Wed, Oct 07, 2020 at 11:08:21 +0200, Peter Krempa wrote: > > On Wed, Oct 07, 2020 at 10:54:54 +0200, Tim Wiederhake wrote: > > > This element is not always present, see e.g. > > > x86_64-cpuid-Xeon-X5460-host.xml, x86_64-cpuid-Pentium-P6100-host.xml, > > > or x86_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml. > > > > Unfortunately this is not enough to persuade me that the change is > > correct though. > > > > Jirka? > > Right, these are just cputest output files so they can't really be used > as an evidence for optional <topology>. > > But it doesn't really matter that much since the host CPU definition is > output only in capabilities XML. APIs that accept host CPU definition as > their input work only on model, vendor, and features thus ignoring any > topology element. > > Also looking at the CPU formatting code we format <topology> only if > (def->sockets && def->dies && def->cores && def->threads). The question > is whether caps->host.cpu would even be allocated when the topology is > unknown. In any case, I think it's fine to mark it as optional in the > schema. Another option would be to mock some topology in cputest to make > sure the host CPU definitions contain the corresponding element. > > Reviewed-by: Jiri Denemark <jdenemar@xxxxxxxxxx> Pushed now. Jirka
