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. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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
