<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/virt/kvm/kvm_main.c, branch linux-3.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.2.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.2.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2016-11-20T01:01:26Z</updated>
<entry>
<title>KVM: nVMX: Fix memory corruption when using VMCS shadowing</title>
<updated>2016-11-20T01:01:26Z</updated>
<author>
<name>Jim Mattson</name>
</author>
<published>2016-07-08T22:36:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c848310491586221cf5f5bf5c5c627e3b78b1757'/>
<id>urn:sha1:c848310491586221cf5f5bf5c5c627e3b78b1757</id>
<content type='text'>
commit 2f1fe81123f59271bddda673b60116bde9660385 upstream.

When freeing the nested resources of a vcpu, there is an assumption that
the vcpu's vmcs01 is the current VMCS on the CPU that executes
nested_release_vmcs12(). If this assumption is violated, the vcpu's
vmcs01 may be made active on multiple CPUs at the same time, in
violation of Intel's specification. Moreover, since the vcpu's vmcs01 is
not VMCLEARed on every CPU on which it is active, it can linger in a
CPU's VMCS cache after it has been freed and potentially
repurposed. Subsequent eviction from the CPU's VMCS cache on a capacity
miss can result in memory corruption.

It is not sufficient for vmx_free_vcpu() to call vmx_load_vmcs01(). If
the vcpu in question was last loaded on a different CPU, it must be
migrated to the current CPU before calling vmx_load_vmcs01().

Signed-off-by: Jim Mattson &lt;jmattson@google.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
[bwh: Backported to 3.2: vcpu_load() returns void]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>kvm: don't take vcpu mutex for obviously invalid vcpu ioctls</title>
<updated>2014-12-14T16:23:44Z</updated>
<author>
<name>David Matlack</name>
</author>
<published>2014-09-19T23:03:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f9b5299d5ae1ba735fa3cc081fd5dc0dc33ba2e8'/>
<id>urn:sha1:f9b5299d5ae1ba735fa3cc081fd5dc0dc33ba2e8</id>
<content type='text'>
commit 2ea75be3219571d0ec009ce20d9971e54af96e09 upstream.

vcpu ioctls can hang the calling thread if issued while a vcpu is running.
However, invalid ioctls can happen when userspace tries to probe the kind
of file descriptors (e.g. isatty() calls ioctl(TCGETS)); in that case,
we know the ioctl is going to be rejected as invalid anyway and we can
fail before trying to take the vcpu mutex.

This patch does not change functionality, it just makes invalid ioctls
fail faster.

Signed-off-by: David Matlack &lt;dmatlack@google.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: Fix iommu map/unmap to handle memory slot moves</title>
<updated>2014-01-03T04:33:35Z</updated>
<author>
<name>Alex Williamson</name>
</author>
<published>2012-12-10T17:32:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=960c9d696b30cfed659cd56d4c7f1bfac7d9c424'/>
<id>urn:sha1:960c9d696b30cfed659cd56d4c7f1bfac7d9c424</id>
<content type='text'>
commit e40f193f5bb022e927a57a4f5d5194e4f12ddb74 upstream.

The iommu integration into memory slots expects memory slots to be
added or removed and doesn't handle the move case.  We can unmap
slots from the iommu after we mark them invalid and map them before
installing the final memslot array.  Also re-order the kmemdup vs
map so we don't leave iommu mappings if we get ENOMEM.

Reviewed-by: Gleb Natapov &lt;gleb@redhat.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: perform an invalid memslot step for gpa base change</title>
<updated>2014-01-03T04:33:35Z</updated>
<author>
<name>Marcelo Tosatti</name>
</author>
<published>2012-08-24T18:54:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c2152747e746aceaa85360eb20b719a835c9d101'/>
<id>urn:sha1:c2152747e746aceaa85360eb20b719a835c9d101</id>
<content type='text'>
commit 12d6e7538e2d418c08f082b1b44ffa5fb7270ed8 upstream.

PPC must flush all translations before the new memory slot
is visible.

Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: Improve create VCPU parameter (CVE-2013-4587)</title>
<updated>2014-01-03T04:33:31Z</updated>
<author>
<name>Andy Honig</name>
</author>
<published>2013-11-19T00:09:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4a94970b318e0d7387c2d84fa7c92ea782ae52b3'/>
<id>urn:sha1:4a94970b318e0d7387c2d84fa7c92ea782ae52b3</id>
<content type='text'>
commit 338c7dbadd2671189cec7faf64c84d01071b3f96 upstream.

In multiple functions the vcpu_id is used as an offset into a bitfield.  Ag
malicious user could specify a vcpu_id greater than 255 in order to set or
clear bits in kernel memory.  This could be used to elevate priveges in the
kernel.  This patch verifies that the vcpu_id provided is less than 255.
The api documentation already specifies that the vcpu_id must be less than
max_vcpus, but this is currently not checked.

Reported-by: Andrew Honig &lt;ahonig@google.com&gt;
Signed-off-by: Andrew Honig &lt;ahonig@google.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: Allow cross page reads and writes from cached translations.</title>
<updated>2013-04-25T19:25:50Z</updated>
<author>
<name>Andrew Honig</name>
</author>
<published>2013-03-29T16:35:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c471da1e3f5c6e43397dccf47cefd8edc86aa9f0'/>
<id>urn:sha1:c471da1e3f5c6e43397dccf47cefd8edc86aa9f0</id>
<content type='text'>
commit 8f964525a121f2ff2df948dac908dcc65be21b5b upstream.

This patch adds support for kvm_gfn_to_hva_cache_init functions for
reads and writes that will cross a page.  If the range falls within
the same memslot, then this will be a fast operation.  If the range
is split between two memslots, then the slower kvm_read_guest and
kvm_write_guest are used.

Tested: Test against kvm_clock unit tests.

Signed-off-by: Andrew Honig &lt;ahonig@google.com&gt;
Signed-off-by: Gleb Natapov &lt;gleb@redhat.com&gt;
[bwh: Backported to 3.2:
 - Drop change in lapic.c
 - Keep using __gfn_to_memslot() in kvm_gfn_to_hva_cache_init()]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: Ensure all vcpus are consistent with in-kernel irqchip settings</title>
<updated>2012-05-30T23:43:10Z</updated>
<author>
<name>Avi Kivity</name>
</author>
<published>2012-03-05T12:23:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=645b177cbfce6b695bdbe0b4c131de584821840d'/>
<id>urn:sha1:645b177cbfce6b695bdbe0b4c131de584821840d</id>
<content type='text'>
(cherry picked from commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e)

If some vcpus are created before KVM_CREATE_IRQCHIP, then
irqchip_in_kernel() and vcpu-&gt;arch.apic will be inconsistent, leading
to potential NULL pointer dereferences.

Fix by:
- ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called
- ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP

This is somewhat long winded because vcpu-&gt;arch.apic is created without
kvm-&gt;lock held.

Based on earlier patch by Michael Ellerman.

Signed-off-by: Michael Ellerman &lt;michael@ellerman.id.au&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: mmu_notifier: Flush TLBs before releasing mmu_lock</title>
<updated>2012-05-30T23:43:09Z</updated>
<author>
<name>Takuya Yoshikawa</name>
</author>
<published>2012-02-10T06:28:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=51155201f92e585d40d8921893a508e8b99b2d0e'/>
<id>urn:sha1:51155201f92e585d40d8921893a508e8b99b2d0e</id>
<content type='text'>
(cherry picked from commit 565f3be2174611f364405bbea2d86e153c2e7e78

Other threads may process the same page in that small window and skip
TLB flush and then return before these functions do flush.

Signed-off-by: Takuya Yoshikawa &lt;yoshikawa.takuya@oss.ntt.co.jp&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: unmap pages from the iommu when slots are removed</title>
<updated>2012-05-11T12:14:07Z</updated>
<author>
<name>Alex Williamson</name>
</author>
<published>2012-04-27T21:54:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1e57aab4e6c549804298f07fac0b6fc77f10fab2'/>
<id>urn:sha1:1e57aab4e6c549804298f07fac0b6fc77f10fab2</id>
<content type='text'>
commit 32f6daad4651a748a58a3ab6da0611862175722f upstream.

We've been adding new mappings, but not destroying old mappings.
This can lead to a page leak as pages are pinned using
get_user_pages, but only unpinned with put_page if they still
exist in the memslots list on vm shutdown.  A memslot that is
destroyed while an iommu domain is enabled for the guest will
therefore result in an elevated page reference count that is
never cleared.

Additionally, without this fix, the iommu is only programmed
with the first translation for a gpa.  This can result in
peer-to-peer errors if a mapping is destroyed and replaced by a
new mapping at the same gpa as the iommu will still be pointing
to the original, pinned memory address.

Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Jonathan Nieder &lt;jrnieder@gmail.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>KVM: Intelligent device lookup on I/O bus</title>
<updated>2011-09-25T16:17:59Z</updated>
<author>
<name>Sasha Levin</name>
</author>
<published>2011-07-27T13:00:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=743eeb0b01d2fbf4154bf87bff1ebb6fb18aeb7a'/>
<id>urn:sha1:743eeb0b01d2fbf4154bf87bff1ebb6fb18aeb7a</id>
<content type='text'>
Currently the method of dealing with an IO operation on a bus (PIO/MMIO)
is to call the read or write callback for each device registered
on the bus until we find a device which handles it.

Since the number of devices on a bus can be significant due to ioeventfds
and coalesced MMIO zones, this leads to a lot of overhead on each IO
operation.

Instead of registering devices, we now register ranges which points to
a device. Lookup is done using an efficient bsearch instead of a linear
search.

Performance test was conducted by comparing exit count per second with
200 ioeventfds created on one byte and the guest is trying to access a
different byte continuously (triggering usermode exits).
Before the patch the guest has achieved 259k exits per second, after the
patch the guest does 274k exits per second.

Cc: Avi Kivity &lt;avi@redhat.com&gt;
Cc: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;levinsasha928@gmail.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
</content>
</entry>
</feed>
