On Feb 15, 2008, at 2:47 PM, Avi Kivity 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. >> > > While enabling gfxboot over vmx is very desirable, I'd like to avoid > guest-specific hacks. IMO the correct fix is to set a > "non_vt_friendly" > flag when switching from real mode to protected mode, then continue > emulation, re-computing the flag after every instruction. After a few > instruction, the condition disappears and we can enter guest mode > again.
So when would the flag disappear? Basically an SS read can happen any time after the switch, even after 100 instructions if it has to. While this should fix more problems, the one thing I am concerned about is that I have not encountered any other code that does have this problem. > The same approach works for big real mode. I agree on that. > The downside is that we have to implement more instructions in the > emulator for this, but these instructions will be generally useful, > not > just for gfxboot. I am not trying to talk you into anything - I would very much prefer a rather clean solution as well. Nevertheless I do not see full protected mode emulation code coming in the very near future and on a user perspective would prefer to have something that works, even if it's ugly. So while KVM is able to run most (if not all?) current major Operating Systems unmodified, it fails to install them (at least on the Linux side). Even though I would greatly appreciate any effort made to get things cleaned up, the gfxboot issue has been standing for months now without even a hacky workaround (except for disabling gfxboot in all) or any visible progress, so I believe a hack like this is at least worth something to distributions that want to enable their users to work with KVM. Alex ------------------------------------------------------------------------- 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
