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

* Avi Kivity <avi@xxxxxxxxxxxx> wrote:

> >Is there no cheap way to do this flushing preemptively (say in 
> >vcpu_put()), to make the VM context potentially loadable into another 
> >CPU?
> 
> You could issue a vmclear, but that forces a vm entry on the _same_ 
> cpu to use vmlaunch instead of vmresume, which is documented as 
> expensive.

hm. Could you try to just do a vmresume nevertheless - maybe it works 
but is undocumented? What would be nice is a 'vmflush' instruction that 
still keeps the state usable.

> It is expected that, in general, VMRESUME will have lower latency than 
> VMLAUNCH. Since “migrating” a VMCS from one logical processor to 
> another requires use of VMCLEAR (see Section 20.10.1), which sets the 
> launch state of the VMCS to “clear,” such migration requires the next 
> VM entry to be performed using VMLAUNCH. Software developers can avoid 
> the performance cost of increased VM-entry latency by avoiding 
> unnecessary migration of a VMCS from one logical processor to another.

doh, very helpful ...

        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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/kvm-devel