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.