On Feb 15, 2008, at 3:56 PM, Anthony Liguori wrote: > Alexander Graf wrote: >> Hi, >> >> this issue has already been talked about previously. Gfxboot on VMX >> is >> broken, because it reads SS after switching from real to protected >> mode, >> where SS contains an invalid value, which VMX does not allow. >> As far as I know, gfxboot is the only application that suffers from >> this >> issue. >> The current "fix" is to make gfxboot use a previously stored SS >> value, >> which works fine for new releases. Already shipped versions of the >> software can not be changed though, so there needs to be another >> way to >> make kvm work with older versions of gfxboot. >> >> 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 >> emulator do a mov realmode_ss, %eax. >> >> This patch implements exactly this idea and fixes openSUSE < 11.0 and >> Ubuntu CD booting on VMX for me. Comments are, as always, welcome. >> > > Have you tried SLES-9 or openSUSE variants of the same age? The ss > issue in gfxboot is only something recently introduced. Prior to > that, gfxboot used big real mode so your patch wouldn't be > sufficient for those versions of gfxboot.
SLES7 - SLES-9 and SUSE 9.1 through to openSUSE 10.1 do not need the patch. They work 'as is'. SLES10 starts in text mode. Starting with 10.2 the mov ss issue came along, but maybe Steffen can tell us more about the history of this issue. > One thing I've thought about is converting gfxboot-disable[1] to > generate a qcow2 that backs to the actual CDROM ISO. Then in QEMU > we could take an MD5 of an ISO if trying to boot from it, compare it > to a white list of known bad CDs, and then generate a qcow2 > automatically with gfxboot disabled. When we eventually support big > real mode in the kernel, we can disable this. This sounds rather hacky too and does not enable the use of gfxboot. Regards, Alex > > > [1] http://hg.codemonkey.ws/gfxboot-disable > > Regards, > > Anthony Liguori > > >> Signed-off-by: Alexander Graf <[EMAIL PROTECTED]> >> >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> 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/ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> kvm-devel mailing list >> kvm-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/kvm-devel > ------------------------------------------------------------------------- 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
