summaryrefslogtreecommitdiffstats
path: root/virt
diff options
context:
space:
mode:
authorAvi Kivity <avi@qumranet.com>2008-05-13 16:22:47 +0300
committerAvi Kivity <avi@qumranet.com>2008-07-20 12:42:24 +0300
commit543e42436643d68ad007d0bae2f485caac9c8a02 (patch)
tree0347cb99587feedb4dfd4520bde416a0bf8ceca9 /virt
parent4ecac3fd6dc2629ad76a658a486f081c44aef10e (diff)
downloadlinux-543e42436643d68ad007d0bae2f485caac9c8a02.tar.gz
linux-543e42436643d68ad007d0bae2f485caac9c8a02.tar.bz2
linux-543e42436643d68ad007d0bae2f485caac9c8a02.zip
KVM: VMX: Add list of potentially locally cached vcpus
VMX hardware can cache the contents of a vcpu's vmcs. This cache needs to be flushed when migrating a vcpu to another cpu, or (which is the case that interests us here) when disabling hardware virtualization on a cpu. The current implementation of decaching iterates over the list of all vcpus, picks the ones that are potentially cached on the cpu that is being offlined, and flushes the cache. The problem is that it uses mutex_trylock() to gain exclusive access to the vcpu, which fires off a (benign) warning about using the mutex in an interrupt context. To avoid this, and to make things generally nicer, add a new per-cpu list of potentially cached vcus. This makes the decaching code much simpler. The list is vmx-specific since other hardware doesn't have this issue. [andrea: fix crash on suspend/resume] Signed-off-by: Andrea Arcangeli <andrea@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions