svm/amd-v not working after upgrade from 10.3 to 11

[Aryeh Friedman]

Does not clear bit 4:

root at lilith:~ # kldunload vmm
kldunload: can't find file vmm
root at lilith:~ # kldload cpuctl
root at lilith:~ # cpucontrol -m 0xc0010114 /dev/cpuctl0
MSR 0xc0010114: 0x00000000 0x00000018
root at lilith:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl0
root at lilith:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl1
root at lilith:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl2
root at lilith:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl3
root at lilith:~ # cpucontrol -m 0xc0010114 /dev/cpuctl0
MSR 0xc0010114: 0x00000000 0x00000018


On Wed, Oct 26, 2016 at 12:46 AM, Anish Gupta <akgupt3 at 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 at svmhost:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl0
>
> If you read and its changed, repeat on all cores.
>
> root at svmhost:~ # cpucontrol -m 0xc0010114=0x8 /dev/cpuctl1
> root at 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 <allanjude at freebsd.org> <allanjude at 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 at 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