Alexander Graf wrote: >> >> 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?
Whenever the register state becomes consistent with VT again. vmx_set_segment() looks like the right point for turning it off. > Basically an SS read can happen any > time after the switch, even after 100 instructions if it has to. That's okay. Most (all) code will reload all segments shortly after the protected mode switch. I am concerned about switches to real-mode not reloading fs and gs, so we'd stay in vt-unfriendly state and emulate even though the real mode code doesn't use fs and gs at all. I believe we can live with it; newer Xen for example emulates 100% of real mode code. > 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. > > I think some Ubuntus use big real mode, which can use the same fix. >> 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). > I'd like to keep ugliness out of the kernel side. I don't think there's much work to get protected mode emulation working. There aren't that many instructions before we get to a vt-friendly state (a couple dozen?) and some of them are already implemented. An alternative is to work around it in userspace. If we recognise the exit reason, we can read the instructions around rip and attempt to fix things up. > 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. On the other hand, merging the hacks discourages the right fix from being developed. I do agree that the current situation is disgraceful. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- 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
