From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jake Thomas Subject: VT-X Locking Bit Flip in Real Mode? Date: Fri, 30 Mar 2012 12:29:59 -0700 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 To: kvm@vger.kernel.org Return-path: Received: from mx1.georgefox.edu ([209.170.248.61]:51896 "EHLO mx1.georgefox.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932551Ab2C3Tgm (ORCPT ); Fri, 30 Mar 2012 15:36:42 -0400 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mx1.georgefox.edu (Postfix) with ESMTP id 21CC3200FA for ; Fri, 30 Mar 2012 12:30:00 -0700 (PDT) Received: by vcqp1 with SMTP id p1so596058vcq.19 for ; Fri, 30 Mar 2012 12:29:59 -0700 (PDT) Sender: kvm-owner@vger.kernel.org List-ID: Hello kvm folk, I saw this: http://www.linux-kvm.org/page/Enable_VT-X_on_Mac_Pro_%28Early_2008%29 , and was intrigued. There is a bit in the MSR that determines whether or not you can turn VT-X (hardware-assisted virtualization) on or off. One bit in the MSR is an on/off switch for turning VT-X on and off, and another bit in the MSR locks this switch. So if it's locked and VT-X is on, you can't turn VT-X off, and if it's locked and VT-X is off, you can't turn VT-X on. But if it's not locked, you can freely turn VT-X on or off and even back. The assumption here is that once the locking bit is in the "locked" position, you can't unlock it until a power cycle unlocks it. Or else it'd be pointless. You'd just flip the locking bit to the "unlocked" position and be on your merry way. But I can't help but wonder if you can flip the locking bit from the "locked" position to the "unlocked" position if you're still in real mode. Because then, one could "simply" write a Grub module to unlock the VT-X switch and/or enable VT-X for you. I envision something like this: grub> insmod vtxunlocker grub> vtxunlocker --unlock grub> vtxunlocker --enable Where in the first line the hypothetical grub module "vtxunlocker" is inserted, making the "vtxunlocker" command available. In the second line, the command "vtxunlocker" is used with the parameter "--unlock" to flip the VT-X locking bit into the "unlocked" posistion. And in the third line, the command "vtxunlocker" is used with the parameter "--enable" to actually enable VT-X by flipping its bit into the "on" position. Remember, this is all happening in real mode because Grub is in real real mode until you decide to boot an OS, or perhaps even past that moment, as is the case with booting Linux (I've read that it's Linux that pushes the big red "protected" button rather than Grub). For sake of completeness, the following probably should also be functionalities and parameters of "vtxunlocker": --lock : puts the VT-X locking bit into the "locked" position --disable : turns VT-X off --isLocked : prints "true" to the screen if the VT-X locking bit is in the "locked" position, "false" if it is in the "unlocked" position --isEnabled : prints "true" to the screen if VT-X is enabled, "false" if it is disabled. --help and -h : prints all possible parameters for vtxunlocker and what they do And of course you can put any of this into a Grub entry in grub.cfg rather than having to break into command line every boot. Such a Grub module would probably be safer than hacking firmware/ firmware settings with dd. It would also be universal from computer to computer. So if a "hack" hasn't been figured out for your computer yet, you could just use the Grub module. And it'd be a lot easier to use. And for ease of use/ practicality/ simplicity, the "vtxunlocker --enable" command would check to see if the VT-X switch is locked, unlock it if it is, and then proceed to enable VT-X, making the second line in the above example unneeded, but good for showing what's going on to n00bs ; D . Cheers, Jake