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>
