<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/powerpc/kvm, branch linux-5.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-08-17T12:42:28Z</updated>
<entry>
<title>powerpc/powernv/kvm: Use darn for H_RANDOM on Power9</title>
<updated>2022-08-17T12:42:28Z</updated>
<author>
<name>Jason A. Donenfeld</name>
</author>
<published>2022-07-27T14:32:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=463a2761d608f260c8c199f0a55161c268fc12b4'/>
<id>urn:sha1:463a2761d608f260c8c199f0a55161c268fc12b4</id>
<content type='text'>
[ Upstream commit 7ef3d06f1bc4a5e62273726f3dc2bd258ae1c71f ]

The existing logic in KVM to support guests calling H_RANDOM only works
on Power8, because it looks for an RNG in the device tree, but on Power9
we just use darn.

In addition the existing code needs to work in real mode, so we have the
special cased powernv_get_random_real_mode() to deal with that.

Instead just have KVM call ppc_md.get_random_seed(), and do the real
mode check inside of there, that way we use whatever RNG is available,
including darn on Power9.

Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.")
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Tested-by: Sachin Sant &lt;sachinp@linux.ibm.com&gt;
[mpe: Rebase on previous commit, update change log appropriately]
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220727143219.2684192-2-mpe@ellerman.id.au
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc: fix typos in comments</title>
<updated>2022-08-17T12:42:11Z</updated>
<author>
<name>Julia Lawall</name>
</author>
<published>2022-04-30T18:56:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=10b11e3558a28163b0f522e5615d62bb8f465cdb'/>
<id>urn:sha1:10b11e3558a28163b0f522e5615d62bb8f465cdb</id>
<content type='text'>
[ Upstream commit 1fd02f6605b855b4af2883f29a2abc88bdf17857 ]

Various spelling mistakes in comments.
Detected with the help of Coccinelle.

Signed-off-by: Julia Lawall &lt;Julia.Lawall@inria.fr&gt;
Reviewed-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220430185654.5855-1-Julia.Lawall@inria.fr
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S HV: Fix vcore_blocked tracepoint</title>
<updated>2022-06-09T08:30:31Z</updated>
<author>
<name>Fabiano Rosas</name>
</author>
<published>2022-03-28T21:58:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eda6f3f9403f94cd64909ec38040d9973e059d23'/>
<id>urn:sha1:eda6f3f9403f94cd64909ec38040d9973e059d23</id>
<content type='text'>
[ Upstream commit ad55bae7dc364417434b69dd6c30104f20d0f84d ]

We removed most of the vcore logic from the P9 path but there's still
a tracepoint that tried to dereference vc-&gt;runner.

Fixes: ecb6a7207f92 ("KVM: PPC: Book3S HV P9: Remove most of the vcore logic")
Signed-off-by: Fabiano Rosas &lt;farosas@linux.ibm.com&gt;
Reviewed-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220328215831.320409-1-farosas@linux.ibm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S HV Nested: L2 LPCR should inherit L1 LPES setting</title>
<updated>2022-06-09T08:29:51Z</updated>
<author>
<name>Nicholas Piggin</name>
</author>
<published>2022-03-03T05:33:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=231d4e455ae2bc097c4013e75663b8d08664751c'/>
<id>urn:sha1:231d4e455ae2bc097c4013e75663b8d08664751c</id>
<content type='text'>
[ Upstream commit 2852ebfa10afdcefff35ec72c8da97141df9845c ]

The L1 should not be able to adjust LPES mode for the L2. Setting LPES
if the L0 needs it clear would cause external interrupts to be sent to
L2 and missed by the L0.

Clearing LPES when it may be set, as typically happens with XIVE enabled
could cause a performance issue despite having no native XIVE support in
the guest, because it will cause mediated interrupts for the L2 to be
taken in HV mode, which then have to be injected.

Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Reviewed-by: Fabiano Rosas &lt;farosas@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220303053315.1056880-7-npiggin@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S HV: fix incorrect NULL check on list iterator</title>
<updated>2022-06-06T06:48:54Z</updated>
<author>
<name>Xiaomeng Tong</name>
</author>
<published>2022-04-14T06:21:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=558ecc747ccf60ce3fc7b5603a0f6a6ccfb9d9ef'/>
<id>urn:sha1:558ecc747ccf60ce3fc7b5603a0f6a6ccfb9d9ef</id>
<content type='text'>
commit 300981abddcb13f8f06ad58f52358b53a8096775 upstream.

The bug is here:
	if (!p)
                return ret;

The list iterator value 'p' will *always* be set and non-NULL by
list_for_each_entry(), so it is incorrect to assume that the iterator
value will be NULL if the list is empty or no element is found.

To fix the bug, Use a new value 'iter' as the list iterator, while use
the old value 'p' as a dedicated variable to point to the found element.

Fixes: dfaa973ae960 ("KVM: PPC: Book3S HV: In H_SVM_INIT_DONE, migrate remaining normal-GFNs to secure-GFNs")
Cc: stable@vger.kernel.org # v5.9+
Signed-off-by: Xiaomeng Tong &lt;xiam0nd.tong@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220414062103.8153-1-xiam0nd.tong@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'powerpc-5.18-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux</title>
<updated>2022-05-15T13:46:03Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2022-05-15T13:46:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bc403203d65a874df2f3156046468052e4109cb0'/>
<id>urn:sha1:bc403203d65a874df2f3156046468052e4109cb0</id>
<content type='text'>
Pull powerpc fix from Michael Ellerman:

 - Fix KVM PR on 32-bit, which was broken by some MMU code refactoring.

Thanks to: Alexander Graf, and Matt Evans.

* tag 'powerpc-5.18-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context()
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context()</title>
<updated>2022-05-11T13:03:16Z</updated>
<author>
<name>Alexander Graf</name>
</author>
<published>2022-05-10T12:37:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ee8348496c77e3737d0a6cda307a521f2cff954f'/>
<id>urn:sha1:ee8348496c77e3737d0a6cda307a521f2cff954f</id>
<content type='text'>
Commit 863771a28e27 ("powerpc/32s: Convert switch_mmu_context() to C")
moved the switch_mmu_context() to C. While in principle a good idea, it
meant that the function now uses the stack. The stack is not accessible
from real mode though.

So to keep calling the function, let's turn on MSR_DR while we call it.
That way, all pointer references to the stack are handled virtually.

In addition, make sure to save/restore r12 on the stack, as it may get
clobbered by the C function.

Fixes: 863771a28e27 ("powerpc/32s: Convert switch_mmu_context() to C")
Cc: stable@vger.kernel.org # v5.14+
Reported-by: Matt Evans &lt;matt@ozlabs.org&gt;
Signed-off-by: Alexander Graf &lt;graf@amazon.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220510123717.24508-1-graf@amazon.com

</content>
</entry>
<entry>
<title>Merge tag 'powerpc-5.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux</title>
<updated>2022-04-24T19:11:20Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2022-04-24T19:11:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5206548f6e6741fccbce8d95cff8faeba0738c99'/>
<id>urn:sha1:5206548f6e6741fccbce8d95cff8faeba0738c99</id>
<content type='text'>
Pull powerpc fixes from Michael Ellerman:

 - Partly revert a change to our timer_interrupt() that caused lockups
   with high res timers disabled.

 - Fix a bug in KVM TCE handling that could corrupt kernel memory.

 - Two commits fixing Power9/Power10 perf alternative event selection.

Thanks to Alexey Kardashevskiy, Athira Rajeev, David Gibson, Frederic
Barrat, Madhavan Srinivasan, Miguel Ojeda, and Nicholas Piggin.

* tag 'powerpc-5.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/perf: Fix 32bit compile
  powerpc/perf: Fix power10 event alternatives
  powerpc/perf: Fix power9 event alternatives
  KVM: PPC: Fix TCE handling for VFIO
  powerpc/time: Always set decrementer in timer_interrupt()
</content>
</entry>
<entry>
<title>KVM: Add helpers to wrap vcpu-&gt;srcu_idx and yell if it's abused</title>
<updated>2022-04-21T17:16:11Z</updated>
<author>
<name>Sean Christopherson</name>
</author>
<published>2022-04-15T00:43:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2031f2876896d82aca7e82f84accd9181b9587fb'/>
<id>urn:sha1:2031f2876896d82aca7e82f84accd9181b9587fb</id>
<content type='text'>
Add wrappers to acquire/release KVM's SRCU lock when stashing the index
in vcpu-&gt;src_idx, along with rudimentary detection of illegal usage,
e.g. re-acquiring SRCU and thus overwriting vcpu-&gt;src_idx.  Because the
SRCU index is (currently) either 0 or 1, illegal nesting bugs can go
unnoticed for quite some time and only cause problems when the nested
lock happens to get a different index.

Wrap the WARNs in PROVE_RCU=y, and make them ONCE, otherwise KVM will
likely yell so loudly that it will bring the kernel to its knees.

Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Tested-by: Fabiano Rosas &lt;farosas@linux.ibm.com&gt;
Message-Id: &lt;20220415004343.2203171-4-seanjc@google.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Fix TCE handling for VFIO</title>
<updated>2022-04-21T07:07:58Z</updated>
<author>
<name>Alexey Kardashevskiy</name>
</author>
<published>2022-04-20T05:08:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=26a62b750a4e6364b0393562f66759b1494c3a01'/>
<id>urn:sha1:26a62b750a4e6364b0393562f66759b1494c3a01</id>
<content type='text'>
The LoPAPR spec defines a guest visible IOMMU with a variable page size.
Currently QEMU advertises 4K, 64K, 2M, 16MB pages, a Linux VM picks
the biggest (16MB). In the case of a passed though PCI device, there is
a hardware IOMMU which does not support all pages sizes from the above -
P8 cannot do 2MB and P9 cannot do 16MB. So for each emulated
16M IOMMU page we may create several smaller mappings ("TCEs") in
the hardware IOMMU.

The code wrongly uses the emulated TCE index instead of hardware TCE
index in error handling. The problem is easier to see on POWER8 with
multi-level TCE tables (when only the first level is preallocated)
as hash mode uses real mode TCE hypercalls handlers.
The kernel starts using indirect tables when VMs get bigger than 128GB
(depends on the max page order).
The very first real mode hcall is going to fail with H_TOO_HARD as
in the real mode we cannot allocate memory for TCEs (we can in the virtual
mode) but on the way out the code attempts to clear hardware TCEs using
emulated TCE indexes which corrupts random kernel memory because
it_offset==1&lt;&lt;59 is subtracted from those indexes and the resulting index
is out of the TCE table bounds.

This fixes kvmppc_clear_tce() to use the correct TCE indexes.

While at it, this fixes TCE cache invalidation which uses emulated TCE
indexes instead of the hardware ones. This went unnoticed as 64bit DMA
is used these days and VMs map all RAM in one go and only then do DMA
and this is when the TCE cache gets populated.

Potentially this could slow down mapping, however normally 16MB
emulated pages are backed by 64K hardware pages so it is one write to
the "TCE Kill" per 256 updates which is not that bad considering the size
of the cache (1024 TCEs or so).

Fixes: ca1fc489cfa0 ("KVM: PPC: Book3S: Allow backing bigger guest IOMMU pages with smaller physical pages")

Signed-off-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Tested-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Reviewed-by: Frederic Barrat &lt;fbarrat@linux.ibm.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220420050840.328223-1-aik@ozlabs.ru

</content>
</entry>
</feed>
