On Thu, Mar 07, 2013 at 01:48:55PM +0100, Jan Kiszka wrote: > On 2013-03-07 13:21, Gleb Natapov wrote: > > On Thu, Mar 07, 2013 at 01:18:24PM +0100, Jan Kiszka wrote: > >> On 2013-03-07 13:05, Gleb Natapov wrote: > >>> On Thu, Mar 07, 2013 at 12:57:27PM +0100, Jan Kiszka wrote: > >>>>>> Ah, sorry, you are not seeing what I'm looking at: The test will change > >>>>>> for L2 context once unrestricted guest mode is added. At that point, it > >>>>>> makes more sense to split it into one version that checks against > >>>>>> VMXON_CR0_ALWAYSON while in vmxon, targeting L1, and another that does > >>>>>> more complex evaluation for L2, depending on nested_cpu_has2(vmcs12, > >>>>>> SECONDARY_EXEC_UNRESTRICTED_GUEST). > >>>>>> > >>>>> Ah, OK. Hard to argue that those checks can be consolidated without > >>>>> seeing them :) So you want to implement unrestricted L1 on restricted L0 and > >>>>> let L0 emulate real mode of L2 directly? > >>>> > >>>> Err, no. :) Well, that emulation might even work but doesn't help unless > >>>> you also emulate EPT (not unrestricted guest mode without EPT support - > >>>> according to the spec). > >>> Yes, of course EPT is needed, but patches are available :) I think it > >>> should speedup L2 real mode substantially. No need to go to L1 for each > >>> instruction emulation and L1 will have to exit to L0 many times during > >>> emulation of some instructions. > >> > >> The point is: If you already have EPT on the host, you likely also have > >> native unrestricted guest mode. You just need to expose it and adjust > >> some minor things (like this bug here) along the way. Not sure how many > >> CPUs had EPT but no unrestricted guest mode. Do you have numbers? > >> > > AFAIK every single one before Westmere. Nehalem does no have it for > > sure. > > OK. Hmm, will it be more than just faking unrestricted mode toward L1 > and emulating in L0 then (which should happen automagically)? Maybe I > will play with this under unrestricted_guest=0 when I have some time. > We will probably need to teach emulator about more instruction that may cause vmexit. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
