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