On 1/22/19 9:37 AM, Stuart Henderson wrote: > On 2019/01/21 21:27, [email protected] wrote: >> >> Architecture: OpenBSD.amd64 >> Machine : amd64 >>> Description: >> On Vsphere 6.0 an OpenBSD guest does recognizes the second cpu but it >> cannot put it online >> The host uses an AMD cpu >>> How-To-Repeat: >> Start a vm on Vsphere 6.0 with smt disabled >>> Fix: >> setting hw.smt=1 is a workaround, a reboot is not needed > > By "with smt disabled" are you talking about disabling vmware's smt support > (System, Advanced System Settings, VMkernel.Boot.hyperthreading) or are you > talking about changing the settings for the individual vm (Configure, > Hardware, Processors, and set as multiple cores *not* multiple "logical > processors")? > VMkernel.Boot.hyperthreading is enabled on Vsphere, I tried setting both 2 cores with 1 logical processor and 1 core with 2 logical processor but it acts the same.
Giovanni > The former affects vmware's scheduler, the latter affects how the virtual > cpu layout is presented to the guest. > >> cpu0 at mainbus0: apid 0 (boot processor) >> cpu0: AMD Opteron(tm) Processor 4386, 3100.71 MHz, 15-10-00 > .. >> cpu0: smt 0, core 0, package 0 > .. >> cpu1 at mainbus0: apid 1 (application processor) >> cpu1: AMD Opteron(tm) Processor 4386, 3100.73 MHz, 15-10-00 > .. >> cpu1: smt 1, core 0, package 0 > > On AMD we can't retrieve a "logical processor id" from the cpu, all we > get is the core/package number and have to imply that a second "cpu" > showing up with the same core/package number is an smt "cpu". > (On intel the relevant cpuid instruction *does* give an "smt id"). > > If vmware is setting this up wrong by default then you might be able to > get around it by changing the advanced option cpuid.coresPerSocket > to have them show up with a different package id (socket = package). > But make sure you're swtting them as cores/sockets not logical > processors first. >
