From owner-freebsd-virtualization@freebsd.org Wed Oct 26 05:14:41 2016 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F11DC2230C for ; Wed, 26 Oct 2016 05:14:41 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35702393 for ; Wed, 26 Oct 2016 05:14:41 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by mail-it0-x229.google.com with SMTP id u205so10622088itc.0 for ; Tue, 25 Oct 2016 22:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=P0+T/WxXn0X8cfBH3wlHYGBTgzZ8bIijLdMNwGNCcT8=; b=lgd2iAWXycGuJ57Uq9YX23o/XZnvaiG7eSbEWqVxATTMBFJozoMEb6i+1iOJyHeH9k aNjQuB5rSpqRg+/5F7QGCQiKF11B7KGDcJaDi1aG51wSLO6WolbJm7GW9zvo29PC7XmJ IhMqeA28LGc6DpTNU+mttl0VbomiGPlmd0WWjPfzRp/5raY1AplL4EIW3fpzLE3qovrW zLW9x3Sgrr3Jvf+7HUDUmMFOwx0UfYCuPs7o4d53gczckkyoOXI5jCx0rFASPjROPPfJ 3dL+vAWf1wF+3RcLH7G2Vhirvr0rSeFXvKSYzm6/SmEWuX7g958U2nr3+tGX4ov+xCBH ia8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=P0+T/WxXn0X8cfBH3wlHYGBTgzZ8bIijLdMNwGNCcT8=; b=cItcpOdCT/cyj1vjdq46peSpHuVUt8v/ckPD6nVOhIAsBrX3o0oZXWOrB6TodZkUkM bTvS3z3r/BdEFsQcTN5HOcpMMWJ62psKnxhtUDPNZB3ZhCQ9TIPVR+8a4MnGHRGvfqhk g6C1LUjzE22RVNfq3BLuLDUw6zFunZSaYLiMtzZctSYARDl7gOP/UiL1vbjYF+c37VwE 3UP1UkOY+jRzAwHTnEVg2SMH6W8odmmOCzD3pYKFHRL1ZUn85Rgo/ZS3Lu9juUMamp9Y Om41XeLUZtHyPFVel2HqIK1hYH+Ga1iaCY+2mEAxTTybXb/SpsRx1BCQ29G3ZKOIE3SO Xw+Q== X-Gm-Message-State: ABUngvfAow/ZlEokdlOuG/RGiLnFuioS6rNF6Mfxefy+7mAFZH8VRk0fS7rj4/wpLLSc7uugaNdd1QFt4lX0bw== X-Received: by 10.107.165.208 with SMTP id o199mr687447ioe.101.1477458880520; Tue, 25 Oct 2016 22:14:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.127.88 with HTTP; Tue, 25 Oct 2016 22:14:40 -0700 (PDT) In-Reply-To: <741c27ff-c5be-6ccf-f147-377e2be8aa2d@gmail.com> References: <741c27ff-c5be-6ccf-f147-377e2be8aa2d@gmail.com> From: Aryeh Friedman Date: Wed, 26 Oct 2016 01:14:40 -0400 Message-ID: Subject: Re: svm/amd-v not working after upgrade from 10.3 to 11 To: Anish Gupta , "freebsd-virtualization@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 05:14:41 -0000 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 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 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: at usbus1 > ugen1.4: at usbus1 > ukbd0 on uhub7 > ukbd0: on usbus1 > kbd2 at ukbd0 > re0: link state changed to UP > ums0 on uhub7 > ums0: on usb= us1 > ums0: 3 buttons and [XYZ] coordinates ID=3D0 > > > > > --=20 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org