Re: [PATCH] enable gfxboot on VMX

[Avi Kivity <avi@qumranet.com>]

Alexander Graf wrote:
>
> 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.
>

For the bootstrap process emulation is good enough, since the process is 
short enough. Good real mode performance may be necessary for 
applications like ghost which are still used for deployment.

In addition, if a real mode app uses x87/mmx/sse, then you are forced to 
add emulation for these instructions if you don't use v8086. Of course, 
if that app also uses big real mode, you are forced to do so anyway,

>>> 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.

No, sorry. This is just from memory.


>> 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?
>

No reason other than it's extremely icky. Looks like Xen has implemented 
it though.

>> 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.

I meant trapping the vmentry failure (this is propagated to userspace 
anyway), recognizing gfxboot, fixing up the state, and continuing.

>
> 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.
>

I can't say I'm thrilled about it when a real fix is possible.

>
> 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?

As I mentioned earlier, deployment apps like ghost.

>
> 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).

Well, I too would really like to see a fix for gfxboot merged, but I 
want to avoid patching whenever possible.

-- 
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/