Alexander Graf wrote: > > On Apr 7, 2008, at 6:51 PM, Anthony Liguori wrote: > >> Alexander Graf wrote: >>> >>> On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote: >>> >>>> Alexander Graf wrote: >>>>> Hi, >>>>> >>>>> this is an improved version of the patch I sent several weeks ago to >>>>> this list. Functionally nothing changed; it still hacks into >>>>> gfxboot and >>>>> patches it to work on Intel CPUs on the fly. The big difference is >>>>> that >>>>> this version is cleaned up and should work with every future CPU >>>>> available. >>>>> >>>>> Please do _not_ apply this patch. I send it to the list only for >>>>> interested people, who would like to have a working version of KVM >>>>> for >>>>> their systems right now. It is neither a proper fix nor the right >>>>> approach to deal with this issue. It is merely a hack that works >>>>> for me >>>>> and maybe for others too. >>>>> >>>> >>>> Perhaps a viable way to fix this upstream would be to catch the >>>> vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke >>>> x86_emulate() in a loop until SS.CPL == CS.CPL. >>>> >>>> There are very few instructions in gfxboot that would need to be >>>> added to x86_emulate (if they aren't already there). >>> >>> In a previous thread Avi already explained a quite reasonable way to >>> approach this problem, which I believe is a really good approach. He >>> wanted to x86_emulate until the environment is "VMX friendly" again, >>> thus resolving big real mode problems as well. >> >> I've got a slightly lamer approach than what Avi probably wants. I >> lost interest in updating x86_emulate once I realized how far xen's >> copy has gotten. To get GFXBOOT 3.3.28 working just requires adding >> far jmp to x86_emulate. The sequence should look like: >> >> jmp pm_seg.prog_c32:switch_to_pm_20 >> switch_to_pm_20: >> >> bits 32 >> >> mov ax,pm_seg.prog_d16 >> mov ds,ax >> mov eax,ss >> >> Which means we'll get 3 vmentry failures. The two moves should >> already be supported by x86_emulate but I haven't confirmed. It's >> not a complete solution to our real mode woes but I think it's a >> reasonable first step. > > Right, this was exactly the approach I wanted to go at first. I just > backed off it as I saw how much ljmp actually does, as normal x86 CPUs > switch to PM not on cr0 setting, but on the ljmp after that. > > So is that simple implementation you have written actually doing the > right thing?
Yes, but it won't compile as KVM does not have a proper load_seg() function like the Xen's x86_emulate. I started copying stuff in but ran against some additional ops (like ->read_segment). I don't think it will be very hard to implement but it exceeded the 45 seconds I was willing to spend looking at it :-) Regards, Anthony Liguori > Regards, > > Alex > >> >> >> Regards, >> >> Anthony Liguori >>> I personally agree that the real approach is way superior to my >>> patch. I just won't have the time to do it in the near future and >>> not being able to boot intuitively hurts KVM users unnecessarily ;-). >>> >>> Regards, >>> >>> Alex >> >> <x86_emulate.patch> > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
