>> The hypercall sequence does not avoid a vmexit. The guest issues a >> vmcall instruction, which is trapped and processed by the host. >> > >Thanks for replying Avi. In your response > (http://article.gmane.org/gmane.linux.kernel/481457) to the announcement >of the > KVM paravirtualization patch you said about the cr3 related hypercall >that: > >"The gain probably comes not only from avoiding the vmentry/vmexit, but >also >from avoiding the flushing of the global page tlb entries." > >Is the vmexit caused by the vmcall more efficient/different than the vmexit >that >is caused by writing to the cr3 register say.
Theoretically speaking the answer is yes, vmcall is a special instruction that it one and only purpose is the exit from the guest. While mov cr3 instruction might be bound to other actions of the processor and might have more effects on the pipeline, this harder to optimize for vmexit purposes. > >Thanks > >Omar Khan > > > > > >----------------------------------------------------------------------- -- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share >your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD EV >_______________________________________________ >kvm-devel mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/kvm-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
