All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jake Thomas <thomasj10@georgefox.edu>
To: kvm@vger.kernel.org
Subject: VT-X Locking Bit Flip in Real Mode?
Date: Fri, 30 Mar 2012 12:29:59 -0700	[thread overview]
Message-ID: <CACO8viqXEUnNsrF9P1xESufxJvorpTL7j6VRPe_kHE1rD5D3hA@mail.gmail.com> (raw)

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

             reply	other threads:[~2012-03-30 19:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30 19:29 Jake Thomas [this message]
2012-03-30 21:12 ` VT-X Locking Bit Flip in Real Mode? Nadav Har'El
2012-03-30 23:24 Jake Thomas
2012-03-30 23:47 ` Jake Thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACO8viqXEUnNsrF9P1xESufxJvorpTL7j6VRPe_kHE1rD5D3hA@mail.gmail.com \
    --to=thomasj10@georgefox.edu \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.