Date: Wed, 26 Oct 2016 01:14:40 -0400 From: Aryeh Friedman <aryeh.friedman@gmail.com> To: Anish Gupta <akgupt3@gmail.com>, "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org> Subject: Re: svm/amd-v not working after upgrade from 10.3 to 11 Message-ID: <CAGBxaX=Y144ye_LX=yOJBYCL8Pq-iadyvhTKjMOpPtrkbkyXqw@mail.gmail.com> In-Reply-To: <741c27ff-c5be-6ccf-f147-377e2be8aa2d@gmail.com> References: <CAGBxaXn3CrKE9hZL-m63B=1e%2BPq6rSKzCDy_F=JZAb7EBqf6Xw@mail.gmail.com> <C119E419-2C0B-4F25-B901-C6BD6B3EC08C@gmail.com> <CAGBxaXm63vMW6svtE-fd9EgVpbjTQ76_18Q3ZQtzPf-wMciVnA@mail.gmail.com> <e6b952a5-0347-486e-ad4e-44d1c8947ff9@freebsd.org> <CAGBxaXkLYOGo5tnixgWNx5SNnKD-3j=Yyygz1H=Hie2xYEvK4w@mail.gmail.com> <741c27ff-c5be-6ccf-f147-377e2be8aa2d@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D0x8 /dev/cpuctl0 root@lilith:~ # cpucontrol -m 0xc0010114=3D0x8 /dev/cpuctl1 root@lilith:~ # cpucontrol -m 0xc0010114=3D0x8 /dev/cpuctl2 root@lilith:~ # cpucontrol -m 0xc0010114=3D0x8 /dev/cpuctl3 root@lilith:~ # cpucontrol -m 0xc0010114 /dev/cpuctl0 MSR 0xc0010114: 0x00000000 0x00000018 On Wed, Oct 26, 2016 at 12:46 AM, Anish Gupta <akgupt3@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=3D0x8 /dev/cpuctl0 > > If you read and its changed, repeat on all cores. > > root@svmhost:~ # cpucontrol -m 0xc0010114=3D0x8 /dev/cpuctl1 > root@svmhost:~ # cpucontrol -m 0xc0010114=3D0x8 /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=E2=80=94Bit 4. When this bit is set, writes to EFER treat the S= VME bit > as MBZ. When this bit is clear, EFER.SVME can be written normally. Thi= s bit > does not prevent CPUID from reporting that SVM is available. Setting S= VMDIS > 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 IN= IT > 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@freebsd.org> <all= anjude@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 usb= us1 > ums0: 3 buttons and [XYZ] coordinates ID=3D0 > > > > > --=20 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaX=Y144ye_LX=yOJBYCL8Pq-iadyvhTKjMOpPtrkbkyXqw>