Brian Jackson wrote:
Andre Przywara wrote:
currently SMP guests happen to see <n> vCPUs as <n> different sockets.
Some guests (Windows comes to mind) have license restrictions and refuse
to run on multi-socket machines.
So lets introduce a "cores=" parameter to the -cpu option to let the user
specify the number of _cores_ the guest should see.
>> ...
Personally, I'd like to see it as an extra arg to the -smp option. We've
seen too many people use -cpu incorrectly in #kvm, so we've gotten into
the habit of telling people not to touch that option unless they know
exactly what they are doing. Plus it seems odd to have to use -cpu foo
when you just want more cpus, not a specific cpu.
Ok, I see your point. I simply used -cpu because of technical reasons
(the core topology is reflected in CPUID, which -cpu cares about). But
you are right, it does not belong here, -smp looks like a good candidate
(IMO better than -numa). Or we use an abstract "-topology" for this, but
this seems like overkill.
So what about: "-smp 4,cores=2,threads=2[,sockets=1]" to inject 4 vCPUs
in one package (automatically determined if omitted) with two cores and
two threads/core? All parameters except the number of vCPUs would be
optional, which would make this new format backwards compatible.
Only we have to agree on the default topology: multi-socket like the
current implementation or multi-core, which would mimic the most common
SMP architecture today. It seems that the latter one causes less
problems for guests.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 488-3567-12
----to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
