<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/powerpc/kvm/powerpc.c, branch linux-4.16.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.16.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.16.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-02-13T04:45:21+00:00</updated>
<entry>
<title>KVM: PPC: Book3S: Fix compile error that occurs with some gcc versions</title>
<updated>2018-02-13T04:45:21+00:00</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@ozlabs.org</email>
</author>
<published>2018-02-13T04:45:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6df3877fc962c2bb3d0438633dfd24a185af6838'/>
<id>urn:sha1:6df3877fc962c2bb3d0438633dfd24a185af6838</id>
<content type='text'>
Some versions of gcc generate a warning that the variable "emulated"
may be used uninitialized in function kvmppc_handle_load128_by2x64().
It would be used uninitialized if kvmppc_handle_load128_by2x64 was
ever called with vcpu-&gt;arch.mmio_vmx_copy_nums == 0, but neither of
the callers ever do that, so there is no actual bug.  When gcc
generates a warning, it causes the build to fail because arch/powerpc
is compiled with -Werror.

This silences the warning by initializing "emulated" to EMULATE_DONE.

Fixes: 09f984961c13 ("KVM: PPC: Book3S: Add MMIO emulation for VMX instructions")
Reported-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Fix compile error that occurs when CONFIG_ALTIVEC=n</title>
<updated>2018-02-13T04:23:39+00:00</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@ozlabs.org</email>
</author>
<published>2018-02-13T04:16:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c662f77331c98018ed256501557b4dd67133fbd7'/>
<id>urn:sha1:c662f77331c98018ed256501557b4dd67133fbd7</id>
<content type='text'>
Commit accb757d798c ("KVM: Move vcpu_load to arch-specific
kvm_arch_vcpu_ioctl_run", 2017-12-04) added a "goto out"
statement and an "out:" label to kvm_arch_vcpu_ioctl_run().
Since the only "goto out" is inside a CONFIG_VSX block,
compiling with CONFIG_VSX=n gives a warning that label "out"
is defined but not used, and because arch/powerpc is compiled
with -Werror, that becomes a compile error that makes the kernel
build fail.

Merge commit 1ab03c072feb ("Merge tag 'kvm-ppc-next-4.16-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc",
2018-02-09) added a similar block of code inside a #ifdef
CONFIG_ALTIVEC, with a "goto out" statement.

In order to make the build succeed, this adds a #ifdef around the
"out:" label.  This is a minimal, ugly fix, to be replaced later
by a refactoring of the code.  Since CONFIG_VSX depends on
CONFIG_ALTIVEC, it is sufficient to use #ifdef CONFIG_ALTIVEC here.

Fixes: accb757d798c ("KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_run")
Reported-by: Christian Zigotzky &lt;chzigotzky@xenosoft.de&gt;
Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'kvm-ppc-next-4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc</title>
<updated>2018-02-09T21:03:06+00:00</updated>
<author>
<name>Radim Krčmář</name>
<email>rkrcmar@redhat.com</email>
</author>
<published>2018-02-09T20:36:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ab03c072feb579c9fd116de25be2b211e6bff6a'/>
<id>urn:sha1:1ab03c072feb579c9fd116de25be2b211e6bff6a</id>
<content type='text'>
Second PPC KVM update for 4.16

Seven fixes that are either trivial or that address bugs that people
are actually hitting.  The main ones are:

- Drop spinlocks before reading guest memory

- Fix a bug causing corruption of VCPU state in PR KVM with preemption
  enabled

- Make HPT resizing work on POWER9

- Add MMIO emulation for vector loads and stores, because guests now
  use these instructions in memcpy and similar routines.
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S: Add MMIO emulation for VMX instructions</title>
<updated>2018-02-09T05:51:51+00:00</updated>
<author>
<name>Jose Ricardo Ziviani</name>
<email>joserz@linux.vnet.ibm.com</email>
</author>
<published>2018-02-03T20:24:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=09f984961c137c4b252c368adab7e1c9f035fa59'/>
<id>urn:sha1:09f984961c137c4b252c368adab7e1c9f035fa59</id>
<content type='text'>
This patch provides the MMIO load/store vector indexed
X-Form emulation.

Instructions implemented:
lvx: the quadword in storage addressed by the result of EA &amp;
0xffff_ffff_ffff_fff0 is loaded into VRT.

stvx: the contents of VRS are stored into the quadword in storage
addressed by the result of EA &amp; 0xffff_ffff_ffff_fff0.

Reported-by: Gopesh Kumar Chaudhary &lt;gopchaud@in.ibm.com&gt;
Reported-by: Balamuruhan S &lt;bala24@linux.vnet.ibm.com&gt;
Signed-off-by: Jose Ricardo Ziviani &lt;joserz@linux.vnet.ibm.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S HV: Make HPT resizing work on POWER9</title>
<updated>2018-02-09T04:36:36+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2018-02-02T03:29:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=790a9df5fbef982f2a6992194fe497dd2b794a3d'/>
<id>urn:sha1:790a9df5fbef982f2a6992194fe497dd2b794a3d</id>
<content type='text'>
This adds code to enable the HPT resizing code to work on POWER9,
which uses a slightly modified HPT entry format compared to POWER8.
On POWER9, we convert HPTEs read from the HPT from the new format to
the old format so that the rest of the HPT resizing code can work as
before.  HPTEs written to the new HPT are converted to the new format
as the last step before writing them into the new HPT.

This takes out the checks added by commit bcd3bb63dbc8 ("KVM: PPC:
Book3S HV: Disable HPT resizing on POWER9 for now", 2017-02-18),
now that HPT resizing works on POWER9.

On POWER9, when we pivot to the new HPT, we now call
kvmppc_setup_partition_table() to update the partition table in order
to make the hardware use the new HPT.

[paulus@ozlabs.org - added kvmppc_setup_partition_table() call,
 wrote commit message.]

Tested-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'kvm-ppc-next-4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc</title>
<updated>2018-02-01T15:13:07+00:00</updated>
<author>
<name>Radim Krčmář</name>
<email>rkrcmar@redhat.com</email>
</author>
<published>2018-02-01T15:13:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d2b9b2079e23c1ab80ce1d7670d5e1994468a881'/>
<id>urn:sha1:d2b9b2079e23c1ab80ce1d7670d5e1994468a881</id>
<content type='text'>
PPC KVM update for 4.16

- Allow HPT guests to run on a radix host on POWER9 v2.2 CPUs
  without requiring the complex thread synchronization that earlier
  CPU versions required.

- A series from Ben Herrenschmidt to improve the handling of
  escalation interrupts with the XIVE interrupt controller.

- Provide for the decrementer register to be copied across on
  migration.

- Various minor cleanups and bugfixes.
</content>
</entry>
<entry>
<title>Merge branch 'x86/hyperv' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2018-02-01T14:04:17+00:00</updated>
<author>
<name>Radim Krčmář</name>
<email>rkrcmar@redhat.com</email>
</author>
<published>2018-02-01T14:04:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7bf14c28ee776be567855bd39ed8ff795ea19f55'/>
<id>urn:sha1:7bf14c28ee776be567855bd39ed8ff795ea19f55</id>
<content type='text'>
Topic branch for stable KVM clockource under Hyper-V.

Thanks to Christoffer Dall for resolving the ARM conflict.
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S: Provide information about hardware/firmware CVE workarounds</title>
<updated>2018-01-19T04:17:01+00:00</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@ozlabs.org</email>
</author>
<published>2018-01-15T05:06:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3214d01f139b7544e870fc0b7fcce8da13c1cb51'/>
<id>urn:sha1:3214d01f139b7544e870fc0b7fcce8da13c1cb51</id>
<content type='text'>
This adds a new ioctl, KVM_PPC_GET_CPU_CHAR, that gives userspace
information about the underlying machine's level of vulnerability
to the recently announced vulnerabilities CVE-2017-5715,
CVE-2017-5753 and CVE-2017-5754, and whether the machine provides
instructions to assist software to work around the vulnerabilities.

The ioctl returns two u64 words describing characteristics of the
CPU and required software behaviour respectively, plus two mask
words which indicate which bits have been filled in by the kernel,
for extensibility.  The bit definitions are the same as for the
new H_GET_CPU_CHARACTERISTICS hypercall.

There is also a new capability, KVM_CAP_PPC_GET_CPU_CHAR, which
indicates whether the new ioctl is available.

Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
</content>
</entry>
<entry>
<title>Merge remote-tracking branch 'remotes/powerpc/topic/ppc-kvm' into kvm-ppc-next</title>
<updated>2018-01-19T01:09:57+00:00</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@ozlabs.org</email>
</author>
<published>2018-01-19T01:09:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d27998185da8fbdc35911307ae13518d168778d7'/>
<id>urn:sha1:d27998185da8fbdc35911307ae13518d168778d7</id>
<content type='text'>
This merges in the ppc-kvm topic branch of the powerpc tree to get
two patches which are prerequisites for the following patch series,
plus another patch which touches both powerpc and KVM code.

Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S HV: Enable migration of decrementer register</title>
<updated>2018-01-16T00:54:45+00:00</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@ozlabs.org</email>
</author>
<published>2018-01-12T09:55:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5855564c8ab2d9cefca7b2933bd19818eb795e40'/>
<id>urn:sha1:5855564c8ab2d9cefca7b2933bd19818eb795e40</id>
<content type='text'>
This adds a register identifier for use with the one_reg interface
to allow the decrementer expiry time to be read and written by
userspace.  The decrementer expiry time is in guest timebase units
and is equal to the sum of the decrementer and the guest timebase.
(The expiry time is used rather than the decrementer value itself
because the expiry time is not constantly changing, though the
decrementer value is, while the guest vcpu is not running.)

Without this, a guest vcpu migrated to a new host will see its
decrementer set to some random value.  On POWER8 and earlier, the
decrementer is 32 bits wide and counts down at 512MHz, so the
guest vcpu will potentially see no decrementer interrupts for up
to about 4 seconds, which will lead to a stall.  With POWER9, the
decrementer is now 56 bits side, so the stall can be much longer
(up to 2.23 years) and more noticeable.

To help work around the problem in cases where userspace has not been
updated to migrate the decrementer expiry time, we now set the
default decrementer expiry at vcpu creation time to the current time
rather than the maximum possible value.  This should mean an
immediate decrementer interrupt when a migrated vcpu starts
running.  In cases where the decrementer is 32 bits wide and more
than 4 seconds elapse between the creation of the vcpu and when it
first runs, the decrementer would have wrapped around to positive
values and there may still be a stall - but this is no worse than
the current situation.  In the large-decrementer case, we are sure
to get an immediate decrementer interrupt (assuming the time from
vcpu creation to first run is less than 2.23 years) and we thus
avoid a very long stall.

Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
</content>
</entry>
</feed>
