<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/virt/kvm/arm/hyp, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/virt/kvm/arm/hyp?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/virt/kvm/arm/hyp?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2020-05-16T14:03:59Z</updated>
<entry>
<title>KVM: arm64: Move virt/kvm/arm to arch/arm64</title>
<updated>2020-05-16T14:03:59Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-05-13T10:40:34Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=9ed24f4b712b855dcf7be3025b75b051cb73a2b7'/>
<id>urn:sha1:9ed24f4b712b855dcf7be3025b75b051cb73a2b7</id>
<content type='text'>
Now that the 32bit KVM/arm host is a distant memory, let's move the
whole of the KVM/arm64 code into the arm64 tree.

As they said in the song: Welcome Home (Sanitarium).

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Acked-by: Will Deacon &lt;will@kernel.org&gt;
Link: https://lore.kernel.org/r/20200513104034.74741-1-maz@kernel.org
</content>
</entry>
<entry>
<title>KVM: arm64: Fix 32bit PC wrap-around</title>
<updated>2020-05-01T08:51:08Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-04-29T10:21:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=0225fd5e0a6a32af7af0aefac45c8ebf19dc5183'/>
<id>urn:sha1:0225fd5e0a6a32af7af0aefac45c8ebf19dc5183</id>
<content type='text'>
In the unlikely event that a 32bit vcpu traps into the hypervisor
on an instruction that is located right at the end of the 32bit
range, the emulation of that instruction is going to increment
PC past the 32bit range. This isn't great, as userspace can then
observe this value and get a bit confused.

Conversly, userspace can do things like (in the context of a 64bit
guest that is capable of 32bit EL0) setting PSTATE to AArch64-EL0,
set PC to a 64bit value, change PSTATE to AArch32-USR, and observe
that PC hasn't been truncated. More confusion.

Fix both by:
- truncating PC increments for 32bit guests
- sanitizing all 32bit regs every time a core reg is changed by
  userspace, and that PSTATE indicates a 32bit mode.

Cc: stable@vger.kernel.org
Acked-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm: vgic-v3: Mark expected switch fall-through</title>
<updated>2019-07-26T14:37:11Z</updated>
<author>
<name>Anders Roxell</name>
<email>anders.roxell@linaro.org</email>
</author>
<published>2019-07-26T11:28:31Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=1a8248c74c81a15a32dc3344fb5c622e19072791'/>
<id>urn:sha1:1a8248c74c81a15a32dc3344fb5c622e19072791</id>
<content type='text'>
When fall-through warnings was enabled by default the following warnings
was starting to show up:

../virt/kvm/arm/hyp/vgic-v3-sr.c: In function ‘__vgic_v3_save_aprs’:
../virt/kvm/arm/hyp/vgic-v3-sr.c:351:24: warning: this statement may fall
 through [-Wimplicit-fallthrough=]
   cpu_if-&gt;vgic_ap0r[2] = __vgic_v3_read_ap0rn(2);
   ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
../virt/kvm/arm/hyp/vgic-v3-sr.c:352:2: note: here
  case 6:
  ^~~~
../virt/kvm/arm/hyp/vgic-v3-sr.c:353:24: warning: this statement may fall
 through [-Wimplicit-fallthrough=]
   cpu_if-&gt;vgic_ap0r[1] = __vgic_v3_read_ap0rn(1);
   ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
../virt/kvm/arm/hyp/vgic-v3-sr.c:354:2: note: here
  default:
  ^~~~~~~

Rework so that the compiler doesn't warn about fall-through.

Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning")
Signed-off-by: Anders Roxell &lt;anders.roxell@linaro.org&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 234</title>
<updated>2019-06-19T15:09:07Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-06-03T05:44:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=caab277b1de0a22b675c4c95fc7b285ec2eb5bf5'/>
<id>urn:sha1:caab277b1de0a22b675c4c95fc7b285ec2eb5bf5</id>
<content type='text'>
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation this program is
  distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details you should have received a copy of the gnu general
  public license along with this program if not see http www gnu org
  licenses

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 503 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Alexios Zavras &lt;alexios.zavras@intel.com&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Reviewed-by: Enrico Weigelt &lt;info@metux.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190602204653.811534538@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: Move cc/it checks under hyp's Makefile to avoid instrumentation</title>
<updated>2019-05-24T13:53:20Z</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2019-05-22T17:47:05Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=623e1528d4090bd1abaf93ec46f047dee9a6fb32'/>
<id>urn:sha1:623e1528d4090bd1abaf93ec46f047dee9a6fb32</id>
<content type='text'>
KVM has helpers to handle the condition codes of trapped aarch32
instructions. These are marked __hyp_text and used from HYP, but they
aren't built by the 'hyp' Makefile, which has all the runes to avoid ASAN
and KCOV instrumentation.

Move this code to a new hyp/aarch32.c to avoid a hyp-panic when starting
an aarch32 guest on a host built with the ASAN/KCOV debug options.

Fixes: 021234ef3752f ("KVM: arm64: Make kvm_condition_valid32() accessible from EL2")
Fixes: 8cebe750c4d9a ("arm64: KVM: Make kvm_skip_instr32 available to HYP")
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: KVM: Always set ICH_HCR_EL2.EN if GICv4 is enabled</title>
<updated>2019-03-19T17:56:34Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2019-03-13T18:07:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=ca71228b42a96908eca7658861eafacd227856c9'/>
<id>urn:sha1:ca71228b42a96908eca7658861eafacd227856c9</id>
<content type='text'>
The normal interrupt flow is not to enable the vgic when no virtual
interrupt is to be injected (i.e. the LRs are empty). But when a guest
is likely to use GICv4 for LPIs, we absolutely need to switch it on
at all times. Otherwise, VLPIs only get delivered when there is something
in the LRs, which doesn't happen very often.

Reported-by: Nianyao Tang &lt;tangnianyao@huawei.com&gt;
Tested-by: Shameerali Kolothum Thodi &lt;shameerali.kolothum.thodi@huawei.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Fix ICH_ELRSR_EL2 sysreg naming</title>
<updated>2019-02-19T21:05:39Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2019-01-04T10:33:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=b98c079ba480c606b13f6abf844187af09baeaab'/>
<id>urn:sha1:b98c079ba480c606b13f6abf844187af09baeaab</id>
<content type='text'>
We previously incorrectly named the define for this system register.

Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: KVM: Consistently advance singlestep when emulating instructions</title>
<updated>2018-12-18T14:11:37Z</updated>
<author>
<name>Mark Rutland</name>
<email>mark.rutland@arm.com</email>
</author>
<published>2018-11-09T15:07:11Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=bd7d95cafb499e24903b7d21f9eeb2c5208160c2'/>
<id>urn:sha1:bd7d95cafb499e24903b7d21f9eeb2c5208160c2</id>
<content type='text'>
When we emulate a guest instruction, we don't advance the hardware
singlestep state machine, and thus the guest will receive a software
step exception after a next instruction which is not emulated by the
host.

We bodge around this in an ad-hoc fashion. Sometimes we explicitly check
whether userspace requested a single step, and fake a debug exception
from within the kernel. Other times, we advance the HW singlestep state
rely on the HW to generate the exception for us. Thus, the observed step
behaviour differs for host and guest.

Let's make this simpler and consistent by always advancing the HW
singlestep state machine when we skip an instruction. Thus we can rely
on the hardware to generate the singlestep exception for us, and never
need to explicitly check for an active-pending step, nor do we need to
fake a debug exception from the guest.

Cc: Peter Maydell &lt;peter.maydell@linaro.org&gt;
Reviewed-by: Alex Bennée &lt;alex.bennee@linaro.org&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'kvm-arm-fixes-for-v4.16-2' into HEAD</title>
<updated>2018-03-19T17:43:01Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2018-03-19T17:43:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=5fbb0df6f68e31a586b947433e93ba9654c8080f'/>
<id>urn:sha1:5fbb0df6f68e31a586b947433e93ba9654c8080f</id>
<content type='text'>
Resolve conflicts with current mainline
</content>
</entry>
<entry>
<title>KVM: arm/arm64: Avoid VGICv3 save/restore on VHE with no IRQs</title>
<updated>2018-03-19T10:53:21Z</updated>
<author>
<name>Christoffer Dall</name>
<email>christoffer.dall@linaro.org</email>
</author>
<published>2017-10-05T15:19:19Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=2d0e63e030babe19c94b4453ef4b272c0aacd75a'/>
<id>urn:sha1:2d0e63e030babe19c94b4453ef4b272c0aacd75a</id>
<content type='text'>
We can finally get completely rid of any calls to the VGICv3
save/restore functions when the AP lists are empty on VHE systems.  This
requires carefully factoring out trap configuration from saving and
restoring state, and carefully choosing what to do on the VHE and
non-VHE path.

One of the challenges is that we cannot save/restore the VMCR lazily
because we can only write the VMCR when ICC_SRE_EL1.SRE is cleared when
emulating a GICv2-on-GICv3, since otherwise all Group-0 interrupts end
up being delivered as FIQ.

To solve this problem, and still provide fast performance in the fast
path of exiting a VM when no interrupts are pending (which also
optimized the latency for actually delivering virtual interrupts coming
from physical interrupts), we orchestrate a dance of only doing the
activate/deactivate traps in vgic load/put for VHE systems (which can
have ICC_SRE_EL1.SRE cleared when running in the host), and doing the
configuration on every round-trip on non-VHE systems.

Signed-off-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
</feed>
