<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/kvm/arm_vgic.h, branch linux-5.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.2.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.2.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-08-16T08:11:11Z</updated>
<entry>
<title>KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block</title>
<updated>2019-08-16T08:11:11Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-08-02T09:28:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=81ccda70dd52f445699d9eb49117df5549ab54ce'/>
<id>urn:sha1:81ccda70dd52f445699d9eb49117df5549ab54ce</id>
<content type='text'>
commit 5eeaf10eec394b28fad2c58f1f5c3a5da0e87d1c upstream.

Since commit commit 328e56647944 ("KVM: arm/arm64: vgic: Defer
touching GICH_VMCR to vcpu_load/put"), we leave ICH_VMCR_EL2 (or
its GICv2 equivalent) loaded as long as we can, only syncing it
back when we're scheduled out.

There is a small snag with that though: kvm_vgic_vcpu_pending_irq(),
which is indirectly called from kvm_vcpu_check_block(), needs to
evaluate the guest's view of ICC_PMR_EL1. At the point were we
call kvm_vcpu_check_block(), the vcpu is still loaded, and whatever
changes to PMR is not visible in memory until we do a vcpu_put().

Things go really south if the guest does the following:

	mov x0, #0	// or any small value masking interrupts
	msr ICC_PMR_EL1, x0

	[vcpu preempted, then rescheduled, VMCR sampled]

	mov x0, #ff	// allow all interrupts
	msr ICC_PMR_EL1, x0
	wfi		// traps to EL2, so samping of VMCR

	[interrupt arrives just after WFI]

Here, the hypervisor's view of PMR is zero, while the guest has enabled
its interrupts. kvm_vgic_vcpu_pending_irq() will then say that no
interrupts are pending (despite an interrupt being received) and we'll
block for no reason. If the guest doesn't have a periodic interrupt
firing once it has blocked, it will stay there forever.

To avoid this unfortuante situation, let's resync VMCR from
kvm_arch_vcpu_blocking(), ensuring that a following kvm_vcpu_check_block()
will observe the latest value of PMR.

This has been found by booting an arm64 Linux guest with the pseudo NMI
feature, and thus using interrupt priorities to mask interrupts instead
of the usual PSTATE masking.

Cc: stable@vger.kernel.org # 4.12
Fixes: 328e56647944 ("KVM: arm/arm64: vgic: Defer touching GICH_VMCR to vcpu_load/put")
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.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://universe.0xinfinity.dev/distro/kernel/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: vgic: Make vgic_cpu-&gt;ap_list_lock a raw_spinlock</title>
<updated>2019-01-24T14:09:09Z</updated>
<author>
<name>Julien Thierry</name>
<email>julien.thierry@arm.com</email>
</author>
<published>2019-01-07T15:06:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e08d8d296079e8fd7eefd53f73dcafebd3a5bf9f'/>
<id>urn:sha1:e08d8d296079e8fd7eefd53f73dcafebd3a5bf9f</id>
<content type='text'>
vgic_cpu-&gt;ap_list_lock must always be taken with interrupts disabled as
it is used in interrupt context.

For configurations such as PREEMPT_RT_FULL, this means that it should
be a raw_spinlock since RT spinlocks are interruptible.

Signed-off-by: Julien Thierry &lt;julien.thierry@arm.com&gt;
Acked-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: vgic: Make vgic_dist-&gt;lpi_list_lock a raw_spinlock</title>
<updated>2019-01-24T14:09:01Z</updated>
<author>
<name>Julien Thierry</name>
<email>julien.thierry@arm.com</email>
</author>
<published>2019-01-07T15:06:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fc3bc475231e12e9c0142f60100cf84d077c79e1'/>
<id>urn:sha1:fc3bc475231e12e9c0142f60100cf84d077c79e1</id>
<content type='text'>
vgic_dist-&gt;lpi_list_lock must always be taken with interrupts disabled as
it is used in interrupt context.

For configurations such as PREEMPT_RT_FULL, this means that it should
be a raw_spinlock since RT spinlocks are interruptible.

Signed-off-by: Julien Thierry &lt;julien.thierry@arm.com&gt;
Acked-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: vgic: Make vgic_irq-&gt;irq_lock a raw_spinlock</title>
<updated>2019-01-24T14:08:50Z</updated>
<author>
<name>Julien Thierry</name>
<email>julien.thierry@arm.com</email>
</author>
<published>2019-01-07T15:06:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8fa3adb8c6beee4af079ac90b9575ab92951de3f'/>
<id>urn:sha1:8fa3adb8c6beee4af079ac90b9575ab92951de3f</id>
<content type='text'>
vgic_irq-&gt;irq_lock must always be taken with interrupts disabled as
it is used in interrupt context.

For configurations such as PREEMPT_RT_FULL, this means that it should
be a raw_spinlock since RT spinlocks are interruptible.

Signed-off-by: Julien Thierry &lt;julien.thierry@arm.com&gt;
Acked-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: vgic-v3: Add core support for Group0 SGIs</title>
<updated>2018-08-12T11:06:34Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2018-08-06T11:51:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6249f2a479268702f7259aeee3671db2be3b922c'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>KVM: arm/arm64: vgic: Let userspace opt-in to writable v2 IGROUPR</title>
<updated>2018-07-21T15:02:29Z</updated>
<author>
<name>Christoffer Dall</name>
<email>christoffer.dall@arm.com</email>
</author>
<published>2018-07-16T13:06:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=32f8777ed92d73e504840a955a9dc92617826b69'/>
<id>urn:sha1:32f8777ed92d73e504840a955a9dc92617826b69</id>
<content type='text'>
Simply letting IGROUPR be writable from userspace would break
migration from old kernels to newer kernels, because old kernels
incorrectly report interrupt groups as group 1.  This would not be a big
problem if userspace wrote GICD_IIDR as read from the kernel, because we
could detect the incompatibility and return an error to userspace.
Unfortunately, this is not the case with current userspace
implementations and simply letting IGROUPR be writable from userspace for
an emulated GICv2 silently breaks migration and causes the destination
VM to no longer run after migration.

We now encourage userspace to write the read and expected value of
GICD_IIDR as the first part of a GIC register restore, and if we observe
a write to GICD_IIDR we know that userspace has been updated and has had
a chance to cope with older kernels (VGICv2 IIDR.Revision == 0)
incorrectly reporting interrupts as group 1, and therefore we now allow
groups to be user writable.

Reviewed-by: Andrew Jones &lt;drjones@redhat.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: vgic: Add group field to struct irq</title>
<updated>2018-07-21T15:02:24Z</updated>
<author>
<name>Christoffer Dall</name>
<email>christoffer.dall@arm.com</email>
</author>
<published>2018-07-16T13:06:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8df3c8f33f46adbaa811c0d57fb1d7eb421b88a9'/>
<id>urn:sha1:8df3c8f33f46adbaa811c0d57fb1d7eb421b88a9</id>
<content type='text'>
In preparation for proper group 0 and group 1 support in the vgic, we
add a field in the struct irq to store the group of all interrupts.

We initialize the group to group 0 when emulating GICv2 and to group 1
when emulating GICv3, just like we treat them today.  LPIs are always
group 1.  We also continue to ignore writes from the guest, preserving
existing functionality, for now.

Finally, we also add this field to the vgic debug logic to show the
group for all interrupts.

Reviewed-by: Andrew Jones &lt;drjones@redhat.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: vgic: Keep track of implementation revision</title>
<updated>2018-07-21T15:02:21Z</updated>
<author>
<name>Christoffer Dall</name>
<email>christoffer.dall@arm.com</email>
</author>
<published>2018-07-16T13:06:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aa075b0f30b53e397fd4d4162ebf4a3a236b9206'/>
<id>urn:sha1:aa075b0f30b53e397fd4d4162ebf4a3a236b9206</id>
<content type='text'>
As we are about to tweak implementation aspects of the VGIC emulation,
while still preserving some level of backwards compatibility support,
add a field to keep track of the implementation revision field which is
reported to the VM and to userspace.

Reviewed-by: Andrew Jones &lt;drjones@redhat.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: Bump VGIC_V3_MAX_CPUS to 512</title>
<updated>2018-05-25T11:29:27Z</updated>
<author>
<name>Eric Auger</name>
<email>eric.auger@redhat.com</email>
</author>
<published>2018-05-22T07:55:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e25028c8ded011d19f9a11164807507c94febc01'/>
<id>urn:sha1:e25028c8ded011d19f9a11164807507c94febc01</id>
<content type='text'>
Let's raise the number of supported vcpus along with
vgic v3 now that HW is looming with more physical CPUs.

Signed-off-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Acked-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
</feed>
