* Avi Kivity <[EMAIL PROTECTED]> wrote:
> 3. The most expensive vmx context switch involves cpu migration:
>
> cpu 0: vmclear vm1 /* decache vmx context into memory */
> cpu 1: vmptrld vm1
> ... vm register access
> vmlaunch
ah. And you optimize this away if previously-used-CPU == curr-CPU and
the vmx context loaded on this CPU is the same as we are trying to run
now, right?
> The vmlaunch instruction, like vmresume, causes a VM entry, but is
> documented to be significantly more expensive. It is required after a
> vmclear.
>
> Currently, the vmclear is performed by an ipi, because we can only
> detect migration after the fact. However, if we enlist the migration
> threads, we can vmclear before the process has left the cpu.
the most common type of migration isnt even in the migration threads but
in simple try_to_wake_up(). And that call often does not run on the CPU
that has the VMX state ...
i see no easy solution here - this really parallels all the lazy-FPU
problems. Would it really be all that expensive to just save/load the
VMX state in switch_to()? As SVN has shown it, we can rely on VMX state
save/load to become faster in the future. So we definitely shouldnt
design for a small-scale overhead in first-generation silicon.
Ingo
-------------------------------------------------------------------------
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
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
