public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Alexander Graf <alex@csgraf.de>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>
Subject: Re: [PATCH] enable gfxboot on VMX
Date: Mon, 18 Feb 2008 12:46:39 +0100	[thread overview]
Message-ID: <p737ih2zduo.fsf@bingen.suse.de> (raw)
In-Reply-To: <47B53B7D.8050209@csgraf.de> (Alexander Graf's message of "Fri\, 15 Feb 2008 08\:13\:01 +0100")

Alexander Graf <alex@csgraf.de> writes:
>
> As everything except gfxboot works, we can simply change gfxboot in
> runtime to use a different value. Unfortunately the mov instruction,
> used to read the SS register is only 2 bytes long, so there is no way to
> binary patch the mov to something that would contain an address. So the
> only way I could think of was an invalid instruction. The UD exception
> is intercepted in KVM and is already emulated for VMCALLs. This can be
> extended to an opcode, that is officially unused (0f 0c) and have the

It quite is dangerous to use unused opcodes like this. Intel/AMD tend
to regularly add new instructions with new CPUs, so currently unused
opcodes can quick turn into used ones which don't trap anymore or trap
differently or do something unexpected. And yes this has broken
software in the past.

If you want to continue to use this method (it is unclear given the
rest of the thread), I would recommend you keep track of the patched
locations instead and use some documented to be trapping 1 or 2 byte opcode
and then check in the #UD handler if you hit one of the previously
patched locations.

Given that solution would have some corner cases (e.g. the table
would likely need to have a fixed upper limit), but at least for the
gfxboot case just using a very small limited table would be probably
enough.

-Andi


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

  parent reply	other threads:[~2008-02-18 11:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-15  7:13 [PATCH] enable gfxboot on VMX Alexander Graf
2008-02-15 13:47 ` Avi Kivity
2008-02-15 13:58   ` Alexander Graf
2008-02-16  9:06     ` Avi Kivity
2008-02-16 13:34       ` Alexander Graf
2008-02-17  8:15         ` Avi Kivity
2008-02-18  9:17         ` Guillaume Thouvenin
2008-02-18  9:34           ` Alexander Graf
2008-02-18  9:39             ` Alexander Graf
2008-02-29 14:34               ` catch vmentry failure (was enable gfxboot on VMX) Guillaume Thouvenin
2008-03-02 17:15                 ` Avi Kivity
2008-02-19  3:37             ` [PATCH] enable gfxboot on VMX Anthony Liguori
2008-02-19  8:26               ` Avi Kivity
2008-02-15 14:56 ` Anthony Liguori
2008-02-15 15:13   ` Alexander Graf
2008-02-15 15:46     ` Steffen Winterfeldt
2008-02-18 11:46 ` Andi Kleen [this message]
2008-02-18 12:04   ` Alexander Graf

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=p737ih2zduo.fsf@bingen.suse.de \
    --to=andi@firstfloor.org \
    --cc=alex@csgraf.de \
    --cc=kvm-devel@lists.sourceforge.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox