<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/arm/kvm, branch v4.19.205</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>KVM: arm: Don't write junk to CP15 registers on reset</title>
<updated>2019-08-29T06:28:48+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-08-05T09:34:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ef61b79017ff626f1ab75afcc37bf1a629449ed1'/>
<id>ef61b79017ff626f1ab75afcc37bf1a629449ed1</id>
<content type='text'>
[ Upstream commit c69509c70aa45a8c4954c88c629a64acf4ee4a36 ]

At the moment, the way we reset CP15 registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.

The "fun" thing is that this can happen while the guest is running
(PSCI, for example). If anything in KVM has to evaluate the state
of a CP15 register while junk is in there, bad thing may happen.

Let's stop doing that. Instead, we track that we have called a
reset function for that register, and assume that the reset
function has done something.

In the end, the very need of this reset check is pretty dubious,
as it doesn't check everything (a lot of the CP15 reg leave outside
of the cp15_regs[] array). It may well be axed in the near future.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit c69509c70aa45a8c4954c88c629a64acf4ee4a36 ]

At the moment, the way we reset CP15 registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.

The "fun" thing is that this can happen while the guest is running
(PSCI, for example). If anything in KVM has to evaluate the state
of a CP15 register while junk is in there, bad thing may happen.

Let's stop doing that. Instead, we track that we have called a
reset function for that register, and assume that the reset
function has done something.

In the end, the very need of this reset check is pretty dubious,
as it doesn't check everything (a lot of the CP15 reg leave outside
of the cp15_regs[] array). It may well be axed in the near future.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: arm/arm64: Move cc/it checks under hyp's Makefile to avoid instrumentation</title>
<updated>2019-06-19T06:18:04+00:00</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2019-05-22T17:47:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=60b300975e5f6c8eb8364fa19d86c2e57a7888e9'/>
<id>60b300975e5f6c8eb8364fa19d86c2e57a7888e9</id>
<content type='text'>
[ Upstream commit 623e1528d4090bd1abaf93ec46f047dee9a6fb32 ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 623e1528d4090bd1abaf93ec46f047dee9a6fb32 ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm/arm64: KVM: Don't panic on failure to properly reset system registers</title>
<updated>2019-03-23T19:09:43+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2018-12-20T13:07:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c831293622b217eb98d56e6c4a141b9a448dd0e7'/>
<id>c831293622b217eb98d56e6c4a141b9a448dd0e7</id>
<content type='text'>
[ Upstream commit 20589c8cc47dce5854c8bf1b44a9fc63d798d26d ]

Failing to properly reset system registers is pretty bad. But not
quite as bad as bringing the whole machine down... So warn loudly,
but slightly more gracefully.

Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Acked-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 20589c8cc47dce5854c8bf1b44a9fc63d798d26d ]

Failing to properly reset system registers is pretty bad. But not
quite as bad as bringing the whole machine down... So warn loudly,
but slightly more gracefully.

Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Acked-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm/arm64: KVM: Allow a VCPU to fully reset itself</title>
<updated>2019-03-23T19:09:43+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2018-12-20T11:36:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b78379c33723a6239f463c66e440e58011546867'/>
<id>b78379c33723a6239f463c66e440e58011546867</id>
<content type='text'>
[ Upstream commit 358b28f09f0ab074d781df72b8a671edb1547789 ]

The current kvm_psci_vcpu_on implementation will directly try to
manipulate the state of the VCPU to reset it.  However, since this is
not done on the thread that runs the VCPU, we can end up in a strangely
corrupted state when the source and target VCPUs are running at the same
time.

Fix this by factoring out all reset logic from the PSCI implementation
and forwarding the required information along with a request to the
target VCPU.

Reviewed-by: Andrew Jones &lt;drjones@redhat.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 358b28f09f0ab074d781df72b8a671edb1547789 ]

The current kvm_psci_vcpu_on implementation will directly try to
manipulate the state of the VCPU to reset it.  However, since this is
not done on the thread that runs the VCPU, we can end up in a strangely
corrupted state when the source and target VCPUs are running at the same
time.

Fix this by factoring out all reset logic from the PSCI implementation
and forwarding the required information along with a request to the
target VCPU.

Reviewed-by: Andrew Jones &lt;drjones@redhat.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: KVM: Correctly order SGI register entries in the cp15 array</title>
<updated>2018-10-09T10:55:47+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2018-10-04T08:35:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ec876f4b252c4084acad259ce3e65ad97f44f040'/>
<id>ec876f4b252c4084acad259ce3e65ad97f44f040</id>
<content type='text'>
The ICC_ASGI1R and ICC_SGI0R register entries in the cp15 array
are not correctly ordered, leading to a BUG() at boot time.

Move them to their natural location.

Fixes: 3e8a8a50c7ef ("KVM: arm: vgic-v3: Add support for ICC_SGI0R and ICC_ASGI1R accesses")
Reported-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Tested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ICC_ASGI1R and ICC_SGI0R register entries in the cp15 array
are not correctly ordered, leading to a BUG() at boot time.

Move them to their natural location.

Fixes: 3e8a8a50c7ef ("KVM: arm: vgic-v3: Add support for ICC_SGI0R and ICC_ASGI1R accesses")
Reported-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Tested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: arm: vgic-v3: Add support for ICC_SGI0R and ICC_ASGI1R accesses</title>
<updated>2018-08-12T11:06:35+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2018-08-06T12:06:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3e8a8a50c7ef1a4f71921731f0e1748a7f70ddaa'/>
<id>3e8a8a50c7ef1a4f71921731f0e1748a7f70ddaa</id>
<content type='text'>
In order to generate Group0 SGIs, let's add some decoding logic to
access_gic_sgi(), and pass the generating group accordingly.

Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to generate Group0 SGIs, let's add some decoding logic to
access_gic_sgi(), and pass the generating group accordingly.

Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: arm/arm64: vgic-v3: Add core support for Group0 SGIs</title>
<updated>2018-08-12T11:06:34+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2018-08-06T11:51:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=6249f2a479268702f7259aeee3671db2be3b922c'/>
<id>6249f2a479268702f7259aeee3671db2be3b922c</id>
<content type='text'>
Although vgic-v3 now supports Group0 interrupts, it still doesn't
deal with Group0 SGIs. As usually with the GIC, nothing is simple:

- ICC_SGI1R can signal SGIs of both groups, since GICD_CTLR.DS==1
  with KVM (as per 8.1.10, Non-secure EL1 access)

- ICC_SGI0R can only generate Group0 SGIs

- ICC_ASGI1R sees its scope refocussed to generate only Group0
  SGIs (as per the note at the bottom of Table 8-14)

We only support Group1 SGIs so far, so no material change.

Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Although vgic-v3 now supports Group0 interrupts, it still doesn't
deal with Group0 SGIs. As usually with the GIC, nothing is simple:

- ICC_SGI1R can signal SGIs of both groups, since GICD_CTLR.DS==1
  with KVM (as per 8.1.10, Non-secure EL1 access)

- ICC_SGI0R can only generate Group0 SGIs

- ICC_ASGI1R sees its scope refocussed to generate only Group0
  SGIs (as per the note at the bottom of Table 8-14)

We only support Group1 SGIs so far, so no material change.

Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: arm: Add 32bit get/set events support</title>
<updated>2018-07-21T15:02:32+00:00</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2018-07-19T15:24:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b0960b9569db6b2fe8a75967d47b9dcdeb44016b'/>
<id>b0960b9569db6b2fe8a75967d47b9dcdeb44016b</id>
<content type='text'>
arm64's new use of KVMs get_events/set_events API calls isn't just
or RAS, it allows an SError that has been made pending by KVM as
part of its device emulation to be migrated.

Wire this up for 32bit too.

We only need to read/write the HCR_VA bit, and check that no esr has
been provided, as we don't yet support VDFSR.

Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Reviewed-by: Dongjiu Geng &lt;gengdongjiu@huawei.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
arm64's new use of KVMs get_events/set_events API calls isn't just
or RAS, it allows an SError that has been made pending by KVM as
part of its device emulation to be migrated.

Wire this up for 32bit too.

We only need to read/write the HCR_VA bit, and check that no esr has
been provided, as we don't yet support VDFSR.

Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Reviewed-by: Dongjiu Geng &lt;gengdongjiu@huawei.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: port KCOV to arm</title>
<updated>2018-06-14T22:55:24+00:00</updated>
<author>
<name>Dmitry Vyukov</name>
<email>dvyukov@google.com</email>
</author>
<published>2018-06-14T22:27:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=758517202bd2e427664857c9f2aa59da36848aca'/>
<id>758517202bd2e427664857c9f2aa59da36848aca</id>
<content type='text'>
KCOV is code coverage collection facility used, in particular, by
syzkaller system call fuzzer.  There is some interest in using syzkaller
on arm devices.  So port KCOV to arm.

On implementation level this merely declares that KCOV is supported and
disables instrumentation of 3 special cases.  Reasons for disabling are
commented in code.

Tested with qemu-system-arm/vexpress-a15.

Link: http://lkml.kernel.org/r/20180511143248.112484-1-dvyukov@google.com
Signed-off-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Acked-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: Abbott Liu &lt;liuwenliang@huawei.com&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Koguchi Takuo &lt;takuo.koguchi.sw@hitachi.com&gt;
Cc: &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
KCOV is code coverage collection facility used, in particular, by
syzkaller system call fuzzer.  There is some interest in using syzkaller
on arm devices.  So port KCOV to arm.

On implementation level this merely declares that KCOV is supported and
disables instrumentation of 3 special cases.  Reasons for disabling are
commented in code.

Tested with qemu-system-arm/vexpress-a15.

Link: http://lkml.kernel.org/r/20180511143248.112484-1-dvyukov@google.com
Signed-off-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Acked-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: Abbott Liu &lt;liuwenliang@huawei.com&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Koguchi Takuo &lt;takuo.koguchi.sw@hitachi.com&gt;
Cc: &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm</title>
<updated>2018-06-06T20:49:25+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-06-06T20:49:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=311da4975894aab7a4bb94aa83f38f052d7ffda4'/>
<id>311da4975894aab7a4bb94aa83f38f052d7ffda4</id>
<content type='text'>
Pull ARM updates from Russell King:

 - Initial round of Spectre variant 1 and variant 2 fixes for 32-bit ARM

 - Clang support improvements

 - nommu updates for v8 MPU

 - enable ARM_MODULE_PLTS by default to avoid problems loading modules
   with larger kernels

 - vmlinux.lds and dma-mapping cleanups

* 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: (31 commits)
  ARM: spectre-v1: fix syscall entry
  ARM: spectre-v1: add array_index_mask_nospec() implementation
  ARM: spectre-v1: add speculation barrier (csdb) macros
  ARM: KVM: report support for SMCCC_ARCH_WORKAROUND_1
  ARM: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
  ARM: spectre-v2: KVM: invalidate icache on guest exit for Brahma B15
  ARM: KVM: invalidate icache on guest exit for Cortex-A15
  ARM: KVM: invalidate BTB on guest exit for Cortex-A12/A17
  ARM: spectre-v2: warn about incorrect context switching functions
  ARM: spectre-v2: add firmware based hardening
  ARM: spectre-v2: harden user aborts in kernel space
  ARM: spectre-v2: add Cortex A8 and A15 validation of the IBE bit
  ARM: spectre-v2: harden branch predictor on context switches
  ARM: spectre: add Kconfig symbol for CPUs vulnerable to Spectre
  ARM: bugs: add support for per-processor bug checking
  ARM: bugs: hook processor bug checking into SMP and suspend paths
  ARM: bugs: prepare processor bug infrastructure
  ARM: add more CPU part numbers for Cortex and Brahma B15 CPUs
  ARM: 8774/1: remove no-op macro VMLINUX_SYMBOL()
  ARM: 8773/1: amba: Export amba_bustype
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ARM updates from Russell King:

 - Initial round of Spectre variant 1 and variant 2 fixes for 32-bit ARM

 - Clang support improvements

 - nommu updates for v8 MPU

 - enable ARM_MODULE_PLTS by default to avoid problems loading modules
   with larger kernels

 - vmlinux.lds and dma-mapping cleanups

* 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: (31 commits)
  ARM: spectre-v1: fix syscall entry
  ARM: spectre-v1: add array_index_mask_nospec() implementation
  ARM: spectre-v1: add speculation barrier (csdb) macros
  ARM: KVM: report support for SMCCC_ARCH_WORKAROUND_1
  ARM: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
  ARM: spectre-v2: KVM: invalidate icache on guest exit for Brahma B15
  ARM: KVM: invalidate icache on guest exit for Cortex-A15
  ARM: KVM: invalidate BTB on guest exit for Cortex-A12/A17
  ARM: spectre-v2: warn about incorrect context switching functions
  ARM: spectre-v2: add firmware based hardening
  ARM: spectre-v2: harden user aborts in kernel space
  ARM: spectre-v2: add Cortex A8 and A15 validation of the IBE bit
  ARM: spectre-v2: harden branch predictor on context switches
  ARM: spectre: add Kconfig symbol for CPUs vulnerable to Spectre
  ARM: bugs: add support for per-processor bug checking
  ARM: bugs: hook processor bug checking into SMP and suspend paths
  ARM: bugs: prepare processor bug infrastructure
  ARM: add more CPU part numbers for Cortex and Brahma B15 CPUs
  ARM: 8774/1: remove no-op macro VMLINUX_SYMBOL()
  ARM: 8773/1: amba: Export amba_bustype
  ...
</pre>
</div>
</content>
</entry>
</feed>
