<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/include/kvm, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/include/kvm?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/include/kvm?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-05-16T16:48:36Z</updated>
<entry>
<title>Merge branch kvm-arm64/per-vcpu-host-pmu-data into kvmarm-master/next</title>
<updated>2022-05-16T16:48:36Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-05-16T16:48:36Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8794b4f510f722f37ae6b583e4b12b1af2fb692a'/>
<id>urn:sha1:8794b4f510f722f37ae6b583e4b12b1af2fb692a</id>
<content type='text'>
* kvm-arm64/per-vcpu-host-pmu-data:
  : .
  : Pass the host PMU state in the vcpu to avoid the use of additional
  : shared memory between EL1 and EL2 (this obviously only applies
  : to nVHE and Protected setups).
  :
  : Patches courtesy of Fuad Tabba.
  : .
  KVM: arm64: pmu: Restore compilation when HW_PERF_EVENTS isn't selected
  KVM: arm64: Reenable pmu in Protected Mode
  KVM: arm64: Pass pmu events to hyp via vcpu
  KVM: arm64: Repack struct kvm_pmu to reduce size
  KVM: arm64: Wrapper for getting pmu_events

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch kvm-arm64/vgic-invlpir into kvmarm-master/next</title>
<updated>2022-05-16T16:48:35Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-05-16T16:48:35Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=ec2cff6cbdbecc4897f97b01992efc0ab86aa492'/>
<id>urn:sha1:ec2cff6cbdbecc4897f97b01992efc0ab86aa492</id>
<content type='text'>
* kvm-arm64/vgic-invlpir:
  : .
  : Implement MMIO-based LPI invalidation for vGICv3.
  : .
  KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR revision
  KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation
  KVM: arm64: vgic-v3: Expose GICR_CTLR.RWP when disabling LPIs
  irqchip/gic-v3: Exposes bit values for GICR_CTLR.{IR, CES}

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch kvm-arm64/hcall-selection into kvmarm-master/next</title>
<updated>2022-05-16T16:47:03Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-05-16T16:47:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=0586e28aaa32ad8eb49b3556eb2f73ae3ca34bd3'/>
<id>urn:sha1:0586e28aaa32ad8eb49b3556eb2f73ae3ca34bd3</id>
<content type='text'>
* kvm-arm64/hcall-selection:
  : .
  : Introduce a new set of virtual sysregs for userspace to
  : select the hypercalls it wants to see exposed to the guest.
  :
  : Patches courtesy of Raghavendra and Oliver.
  : .
  KVM: arm64: Fix hypercall bitmap writeback when vcpus have already run
  KVM: arm64: Hide KVM_REG_ARM_*_BMAP_BIT_COUNT from userspace
  Documentation: Fix index.rst after psci.rst renaming
  selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list
  selftests: KVM: aarch64: Introduce hypercall ABI test
  selftests: KVM: Create helper for making SMCCC calls
  selftests: KVM: Rename psci_cpu_on_test to psci_test
  tools: Import ARM SMCCC definitions
  Docs: KVM: Add doc for the bitmap firmware registers
  Docs: KVM: Rename psci.rst to hypercalls.rst
  KVM: arm64: Add vendor hypervisor firmware register
  KVM: arm64: Add standard hypervisor firmware register
  KVM: arm64: Setup a framework for hypercall bitmap firmware registers
  KVM: arm64: Factor out firmware register handling from psci.c

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: pmu: Restore compilation when HW_PERF_EVENTS isn't selected</title>
<updated>2022-05-16T12:42:41Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-05-16T12:02:24Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=20492a62b99bd4367b79a76ca288d018f11980db'/>
<id>urn:sha1:20492a62b99bd4367b79a76ca288d018f11980db</id>
<content type='text'>
Moving kvm_pmu_events into the vcpu (and refering to it) broke the
somewhat unusual case where the kernel has no support for a PMU
at all.

In order to solve this, move things around a bit so that we can
easily avoid refering to the pmu structure outside of PMU-aware
code. As a bonus, pmu.c isn't compiled in when HW_PERF_EVENTS
isn't selected.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Reviewed-by: Fuad Tabba &lt;tabba@google.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/202205161814.KQHpOzsJ-lkp@intel.com
</content>
</entry>
<entry>
<title>KVM: arm64: Pass pmu events to hyp via vcpu</title>
<updated>2022-05-15T10:26:41Z</updated>
<author>
<name>Fuad Tabba</name>
<email>tabba@google.com</email>
</author>
<published>2022-05-10T09:57:09Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=84d751a019a9792f5b4884e1d598b603c360ec22'/>
<id>urn:sha1:84d751a019a9792f5b4884e1d598b603c360ec22</id>
<content type='text'>
Instead of the host accessing hyp data directly, pass the pmu
events of the current cpu to hyp via the vcpu.

This adds 64 bits (in two fields) to the vcpu that need to be
synced before every vcpu run in nvhe and protected modes.
However, it isolates the hypervisor from the host, which allows
us to use pmu in protected mode in a subsequent patch.

No visible side effects in behavior intended.

Signed-off-by: Fuad Tabba &lt;tabba@google.com&gt;
Reviewed-by: Oliver Upton &lt;oupton@google.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20220510095710.148178-4-tabba@google.com
</content>
</entry>
<entry>
<title>KVM: arm64: Repack struct kvm_pmu to reduce size</title>
<updated>2022-05-15T10:24:17Z</updated>
<author>
<name>Fuad Tabba</name>
<email>tabba@google.com</email>
</author>
<published>2022-05-10T09:57:08Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=e987a4c60f9755b2f7a19bf1b5ef2eb74c90579b'/>
<id>urn:sha1:e987a4c60f9755b2f7a19bf1b5ef2eb74c90579b</id>
<content type='text'>
struct kvm_pmu has 2 holes using 10 bytes. This is instantiated
in all vcpus, so it adds up. Repack the structures to remove the
holes.

No functional change intended.

Reviewed-by: Oliver Upton &lt;oupton@google.com&gt;
Signed-off-by: Fuad Tabba &lt;tabba@google.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20220510095710.148178-3-tabba@google.com
</content>
</entry>
<entry>
<title>KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR revision</title>
<updated>2022-05-04T13:09:53Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-04-05T18:23:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=49a1a2c70a7fd820fe60a65a3e38ab9095082dc9'/>
<id>urn:sha1:49a1a2c70a7fd820fe60a65a3e38ab9095082dc9</id>
<content type='text'>
Since adversising GICR_CTLR.{IC,CES} is directly observable from
a guest, we need to make it selectable from userspace.

For that, bump the default GICD_IIDR revision and let userspace
downgrade it to the previous default. For GICv2, the two distributor
revisions are strictly equivalent.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20220405182327.205520-5-maz@kernel.org
</content>
</entry>
<entry>
<title>KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation</title>
<updated>2022-05-04T13:09:53Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-04-05T18:23:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=4645d11f4a5538ec1221f36e397cfb0115718ffe'/>
<id>urn:sha1:4645d11f4a5538ec1221f36e397cfb0115718ffe</id>
<content type='text'>
Since GICv4.1, it has become legal for an implementation to advertise
GICR_{INVLPIR,INVALLR,SYNCR} while having an ITS, allowing for a more
efficient invalidation scheme (no guest command queue contention when
multiple CPUs are generating invalidations).

Provide the invalidation registers as a primitive to their ITS
counterpart. Note that we don't advertise them to the guest yet
(the architecture allows an implementation to do this).

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Oliver Upton &lt;oupton@google.com&gt;
Link: https://lore.kernel.org/r/20220405182327.205520-4-maz@kernel.org
</content>
</entry>
<entry>
<title>KVM: arm64: vgic-v3: Expose GICR_CTLR.RWP when disabling LPIs</title>
<updated>2022-05-04T13:09:53Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-04-05T18:23:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=94828468a6085e6ae148986d300b634b87f86516'/>
<id>urn:sha1:94828468a6085e6ae148986d300b634b87f86516</id>
<content type='text'>
When disabling LPIs, a guest needs to poll GICR_CTLR.RWP in order
to be sure that the write has taken effect. We so far reported it
as 0, as we didn't advertise that LPIs could be turned off the
first place.

Start tracking this state during which LPIs are being disabled,
and expose the 'in progress' state via the RWP bit.

We also take this opportunity to disallow enabling LPIs and programming
GICR_{PEND,PROP}BASER while LPI disabling is in progress, as allowed by
the architecture (UNPRED behaviour).

We don't advertise the feature to the guest yet (which is allowed by
the architecture).

Reviewed-by: Oliver Upton &lt;oupton@google.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20220405182327.205520-3-maz@kernel.org
</content>
</entry>
<entry>
<title>KVM: arm64: Setup a framework for hypercall bitmap firmware registers</title>
<updated>2022-05-03T20:30:19Z</updated>
<author>
<name>Raghavendra Rao Ananta</name>
<email>rananta@google.com</email>
</author>
<published>2022-05-02T23:38:46Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=05714cab7d63b189894235cf310fae7d6ffc2e9b'/>
<id>urn:sha1:05714cab7d63b189894235cf310fae7d6ffc2e9b</id>
<content type='text'>
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.

As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.

These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.

During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.

Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.

Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.

In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.

Signed-off-by: Raghavendra Rao Ananta &lt;rananta@google.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
 dropped error-only fast path]
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
</content>
</entry>
</feed>
