On Tue, Jun 12, 2018 at 06:38:08PM +0000, Moger, Babu wrote: [...] > > I'm starting to think that enabling TOPOEXT automatically is > > adding too much complexity and compatibility problems, and it's > > better to leave this task to management software. > > > > The main problem here is: > > > > This works today with QEMU 2.12 + Linux <= 4.15: > > $ $QEMU -machine pc -cpu EPYC,enforce -smp > > 8,sockets=2,cores=2,threads=2" > > and must keep working with QEMU 3.0 and Linux <= 4.15. > > > > In addition to that, the results for: > > $ $QEMU -machine pc-q35-3.0 -cpu EPYC,enforce [...] > > must be deterministic and expose exactly the same CPUID data even > > if host hardware or software changes, as long as the QEMU > > command-line is the same. > > > > Do you see a way to fulfill those two constraints while making > > "-machine pc-q35-3.0 -cpu EPYC" enable TOPOEXT automatically? > > > > Now(setting feature before x86_cpu_expand_features), enabling > TOPOEXT appears to work fine. What about the above constraints? Are you really fulfilling them? This one is tricky: ] This works today with QEMU 2.12 + Linux <= 4.15: ] $ $QEMU -machine pc -cpu EPYC,enforce -smp 8,sockets=2,cores=2,threads=2" ] and must keep working with QEMU 3.0 and Linux <= 4.15. If we enable TOPOEXT unconditionally, the command-line won't work with Linux <= 4.15. If we enable TOPOEXT only if the kernel returns TOPOEXT on GET_SUPPORTED_CPUID, we break the second constraint: ] The results for: ] $ $QEMU -machine pc-q35-3.0 -cpu EPYC,enforce [...] ] must be deterministic and expose exactly the same CPUID data even ] if host hardware or software changes, as long as the QEMU ] command-line is the same. -- Eduardo
