Does not clear bit 4: root@lilith:~ # kldunload vmm kldunload: can't find file vmm root@lilith:~ # kldload cpuctl root@lilith:~ # cpucontrol -m 0xc0010114 /dev/cpuctl0 MSR 0xc0010114: 0x00000000 0x00000018 root@lilith:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl0 root@lilith:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl1 root@lilith:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl2 root@lilith:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl3 root@lilith:~ # cpucontrol -m 0xc0010114 /dev/cpuctl0 MSR 0xc0010114: 0x00000000 0x00000018
On Wed, Oct 26, 2016 at 12:46 AM, Anish Gupta <akgu...@gmail.com> wrote: > You can give this a shot, doesn't look like it will work as per spec but I > don't see any harm. Power cycling the system will clear all errors. > > Unload vmm > > $kldunload vmm > > $kldload cpuctl << To read/write MSR > > Check VM_CR MSR[0xC001_0114] MSR Bit4, must be clear. > > $cpucontrol -m 0xc0010114 /dev/cpuctl0 > MSR 0xc0010114: 0x00000000 0x00000008 << Bit4 clear on my AMD box > > If not, write to clear it. > > root@svmhost:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl0 > > If you read and its changed, repeat on all cores. > > root@svmhost:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl1 > root@svmhost:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl2 > ... > > Now load vmm.ko module. If write was successful, SVM might work. > > Looks like its not possible to change bit4/SVMDIS of VM_CR, as per APM2 > > > - > > SVMDIS—Bit 4. When this bit is set, writes to EFER treat the SVME bit > as MBZ. When this bit is clear, EFER.SVME can be written normally. This bit > does not prevent CPUID from reporting that SVM is available. Setting SVMDIS > while EFER.SVME is 1 generates a #GP fault, regardless of the current state > of VM_CR.LOCK. This bit is not affected by SKINIT. It is cleared by INIT > when LOCK is cleared to 0; otherwise, it is not affected. > > -Anish > On 10/25/16 7:37 PM, Aryeh Friedman wrote: > > On Tue, Oct 25, 2016 at 10:34 PM, Allan Jude <allanj...@freebsd.org> > <allanj...@freebsd.org> wrote: > > > The file /var/run/dmesg.boot will have a copy of dmesg from when the > machine booted. > > > > It was even smaller then normal dmesg output here is the file: > > root@lilith:/usr/src # more /var/run/dmesg.boot > uhub7: 4 ports with 4 removable, self powered > ugen1.3: <PixArt> at usbus1 > ugen1.4: <LITEON Technology> at usbus1 > ukbd0 on uhub7 > ukbd0: <EP1 Interrupt> on usbus1 > kbd2 at ukbd0 > re0: link state changed to UP > ums0 on uhub7 > ums0: <PixArt USB Optical Mouse, class 0/0, rev 2.00/1.00, addr 3> on usbus1 > ums0: 3 buttons and [XYZ] coordinates ID=0 > > > > > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"