<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/mips/kvm/emulate.c, branch linux-4.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2016-11-18T09:48:36Z</updated>
<entry>
<title>KVM: MIPS: Precalculate MMIO load resume PC</title>
<updated>2016-11-18T09:48:36Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2016-10-25T15:11:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d7b0055e5566439602753376ebc69d37ca0d6990'/>
<id>urn:sha1:d7b0055e5566439602753376ebc69d37ca0d6990</id>
<content type='text'>
commit e1e575f6b026734be3b1f075e780e91ab08ca541 upstream.

The advancing of the PC when completing an MMIO load is done before
re-entering the guest, i.e. before restoring the guest ASID. However if
the load is in a branch delay slot it may need to access guest code to
read the prior branch instruction. This isn't safe in TLB mapped code at
the moment, nor in the future when we'll access unmapped guest segments
using direct user accessors too, as it could read the branch from host
user memory instead.

Therefore calculate the resume PC in advance while we're still in the
right context and save it in the new vcpu-&gt;arch.io_pc (replacing the no
longer needed vcpu-&gt;arch.pending_load_cause), and restore it on MMIO
completion.

Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim Krčmář" &lt;rkrcmar@redhat.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
[james.hogan@imgtec.com: Backport to 3.18..4.4]
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>KVM: MIPS: Drop other CPU ASIDs on guest MMU changes</title>
<updated>2016-11-15T06:46:39Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2016-09-15T16:20:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=72c13445dfb40e5d14d2d9fdc3c5ee61915a69fe'/>
<id>urn:sha1:72c13445dfb40e5d14d2d9fdc3c5ee61915a69fe</id>
<content type='text'>
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.

When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate
TLB entries on the local CPU. This doesn't work correctly on an SMP host
when the guest is migrated to a different physical CPU, as it could pick
up stale TLB mappings from the last time the vCPU ran on that physical
CPU.

Therefore invalidate both user and kernel host ASIDs on other CPUs,
which will cause new ASIDs to be generated when it next runs on those
CPUs.

We're careful only to do this if the TLB entry was already valid, and
only for the kernel ASID where the virtual address it mapped is outside
of the guest user address range.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim Krčmář" &lt;rkrcmar@redhat.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.17.x-
[james.hogan@imgtec.com: Backport to 3.17..4.4]
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert KVM: MIPS: Drop other CPU ASIDs on guest MMU changes</title>
<updated>2016-11-15T06:46:39Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
</author>
<published>2016-11-13T11:16:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c57deabd2b17409fb6bc671f4cd1499e720be4b4'/>
<id>urn:sha1:c57deabd2b17409fb6bc671f4cd1499e720be4b4</id>
<content type='text'>
This reverts commit d450527ad04ad180636679aeb3161ec58079f1ba which was
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream as it was
incorrect.  A fixed version will be forthcoming.

Reported-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim Krčmář" &lt;rkrcmar@redhat.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>KVM: MIPS: Make ERET handle ERL before EXL</title>
<updated>2016-11-10T15:36:34Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2016-10-25T15:11:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ab69d3a03e2253b3029447887a8883606e7be844'/>
<id>urn:sha1:ab69d3a03e2253b3029447887a8883606e7be844</id>
<content type='text'>
commit ede5f3e7b54a4347be4d8525269eae50902bd7cd upstream.

The ERET instruction to return from exception is used for returning from
exception level (Status.EXL) and error level (Status.ERL). If both bits
are set however we should be returning from ERL first, as ERL can
interrupt EXL, for example when an NMI is taken. KVM however checks EXL
first.

Fix the order of the checks to match the pseudocode in the instruction
set manual.

Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim Krčmář" &lt;rkrcmar@redhat.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>KVM: MIPS: Drop other CPU ASIDs on guest MMU changes</title>
<updated>2016-10-16T15:36:14Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2016-09-15T16:20:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d450527ad04ad180636679aeb3161ec58079f1ba'/>
<id>urn:sha1:d450527ad04ad180636679aeb3161ec58079f1ba</id>
<content type='text'>
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.

When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate
TLB entries on the local CPU. This doesn't work correctly on an SMP host
when the guest is migrated to a different physical CPU, as it could pick
up stale TLB mappings from the last time the vCPU ran on that physical
CPU.

Therefore invalidate both user and kernel host ASIDs on other CPUs,
which will cause new ASIDs to be generated when it next runs on those
CPUs.

We're careful only to do this if the TLB entry was already valid, and
only for the kernel ASID where the virtual address it mapped is outside
of the guest user address range.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim Krčmář" &lt;rkrcmar@redhat.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>MIPS: KVM: Propagate kseg0/mapped tlb fault errors</title>
<updated>2016-08-20T16:09:21Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2016-08-18T09:05:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4fa571ebe60f311c885b37a3dcfbf961e5fbd57d'/>
<id>urn:sha1:4fa571ebe60f311c885b37a3dcfbf961e5fbd57d</id>
<content type='text'>
commit 9b731bcfdec4c159ad2e4312e25d69221709b96a upstream.

Propagate errors from kvm_mips_handle_kseg0_tlb_fault() and
kvm_mips_handle_mapped_seg_tlb_fault(), usually triggering an internal
error since they normally indicate the guest accessed bad physical
memory or the commpage in an unexpected way.

Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim Krčmář" &lt;rkrcmar@redhat.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Radim Krčmář &lt;rkrcmar@redhat.com&gt;
[james.hogan@imgtec.com: Backport to v3.17.y - v4.4.y]
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>MIPS: KVM: Fix timer IRQ race when writing CP0_Compare</title>
<updated>2016-06-01T19:15:52Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2016-04-22T09:38:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a6fa60f5614352eb53fc57b23f1984fed4e71eac'/>
<id>urn:sha1:a6fa60f5614352eb53fc57b23f1984fed4e71eac</id>
<content type='text'>
commit b45bacd2d048f405c7760e5cc9b60dd67708734f upstream.

Writing CP0_Compare clears the timer interrupt pending bit
(CP0_Cause.TI), but this wasn't being done atomically. If a timer
interrupt raced with the write of the guest CP0_Compare, the timer
interrupt could end up being pending even though the new CP0_Compare is
nowhere near CP0_Count.

We were already updating the hrtimer expiry with
kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and
kvm_mips_resume_hrtimer(). Close the race window by expanding out
kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting
CP0_Compare between the freeze and resume. Since the pending timer
interrupt should not be cleared when CP0_Compare is written via the KVM
user API, an ack argument is added to distinguish the source of the
write.

Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim KrÄmÃ¡Å™" &lt;rkrcmar@redhat.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>MIPS: KVM: Fix timer IRQ race when freezing timer</title>
<updated>2016-06-01T19:15:52Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2016-04-22T09:38:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9e01c02f98f98c03cba7e147577364b667d03808'/>
<id>urn:sha1:9e01c02f98f98c03cba7e147577364b667d03808</id>
<content type='text'>
commit 4355c44f063d3de4f072d796604c7f4ba4085cc3 upstream.

There's a particularly narrow and subtle race condition when the
software emulated guest timer is frozen which can allow a guest timer
interrupt to be missed.

This happens due to the hrtimer expiry being inexact, so very
occasionally the freeze time will be after the moment when the emulated
CP0_Count transitions to the same value as CP0_Compare (so an IRQ should
be generated), but before the moment when the hrtimer is due to expire
(so no IRQ is generated). The IRQ won't be generated when the timer is
resumed either, since the resume CP0_Count will already match CP0_Compare.

With VZ guests in particular this is far more likely to happen, since
the soft timer may be frozen frequently in order to restore the timer
state to the hardware guest timer. This happens after 5-10 hours of
guest soak testing, resulting in an overflow in guest kernel timekeeping
calculations, hanging the guest. A more focussed test case to
intentionally hit the race (with the help of a new hypcall to cause the
timer state to migrated between hardware &amp; software) hits the condition
fairly reliably within around 30 seconds.

Instead of relying purely on the inexact hrtimer expiry to determine
whether an IRQ should be generated, read the guest CP0_Compare and
directly check whether the freeze time is before or after it. Only if
CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to
determine whether the last IRQ has already been generated (which will
have pushed back the expiry by one timer period).

Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim KrÄmÃ¡Å™" &lt;rkrcmar@redhat.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>MIPS: KVM: Fix CACHE immediate offset sign extension</title>
<updated>2015-11-18T11:25:36Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2015-11-11T14:21:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c5c2a3b998f1ff5a586f9d37e154070b8d550d17'/>
<id>urn:sha1:c5c2a3b998f1ff5a586f9d37e154070b8d550d17</id>
<content type='text'>
The immediate field of the CACHE instruction is signed, so ensure that
it gets sign extended by casting it to an int16_t rather than just
masking the low 16 bits.

Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Gleb Natapov &lt;gleb@kernel.org&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.10.x-
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>MIPS: KVM: Do not sign extend on unsigned MMIO load</title>
<updated>2015-06-06T08:21:10Z</updated>
<author>
<name>Nicholas Mc Guire</name>
</author>
<published>2015-05-07T12:47:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ed9244e6c534612d2b5ae47feab2f55a0d4b4ced'/>
<id>urn:sha1:ed9244e6c534612d2b5ae47feab2f55a0d4b4ced</id>
<content type='text'>
Fix possible unintended sign extension in unsigned MMIO loads by casting
to uint16_t in the case of mmio_needed != 2.

Signed-off-by: Nicholas Mc Guire &lt;hofrat@osadl.org&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Tested-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Gleb Natapov &lt;gleb@kernel.org&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9985/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
</feed>
