On Feb 16, 2008, at 10:06 AM, Avi Kivity wrote: > 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.
Sounds good. As basically the only problem we have are the sanity checks done on VMENTER, this should work. >> 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. Emulating all of the real mode shouldn't be too much of a problem on the performance side. I wouldn't be surprised if the vmenter/exits take about as much time as the emulation overhead. >> 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. Do you have any file / pointer to where I could get one? I did try the feisty server iso which worked just fine. >>> 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. The hardest one being ljmp. You need to do the whole pm transition in the emulator then. I believe there is a reason this hasn't been done yet? > 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. So just get the CR0 write and UD exception as event to the userspace? I'd really love that approach. The "invalid opcode" hack, as I implemented it, is actually quite extensible. You could simply put the rip and an operation that is supposed to occur in a list and emulate whatever comes when the UD occurs. This might be the easiest way to fix things. We could also have something more extensible, say a "generic binary patching" framework, so we know that if memory page 0x1234000 contains specific content, just patch it and apply a "what happens in case of invalid opcodes" script. This could all be in userspace and should enable us to circumvent most problems in a generic way. >> 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. Don't get me wrong on this - I really want to see something "right". I just don't see anyone working on it, as there are a lot of places KVM improves right now, which are a lot more important than real mode fixes. Usually real mode is completely unused as soon as you're done with bootstrapping, so why care about it that much? I'm also perfectly fine with this not being merged. I built this hack for me, because I was rather unhappy with the situation as is and wanted to see gfxboot working, as I couldn't just "plug in" a current iso and install from that. If anyone benefits from it, I'm fine with it. If not, that's ok with me too. I just couldn't stand the situation that no fix was available at all (disabling gfxboot was no fix for me). 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
