Re: [PATCH 0/8] KVM updates for 2.6.20-rc2

[Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>]

* Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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