<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/Documentation/virtual/kvm/api.txt, branch linux-4.16.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.16.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.16.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2018-05-01T19:47:30Z</updated>
<entry>
<title>arm/arm64: KVM: Add PSCI version selection API</title>
<updated>2018-05-01T19:47:30Z</updated>
<author>
<name>Marc Zyngier</name>
</author>
<published>2018-01-21T16:42:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=020d0df523770d905fbabb1e16062a0746fef37a'/>
<id>urn:sha1:020d0df523770d905fbabb1e16062a0746fef37a</id>
<content type='text'>
commit 85bd0ba1ff9875798fad94218b627ea9f768f3c3 upstream.

Although we've implemented PSCI 0.1, 0.2 and 1.0, we expose either 0.1
or 1.0 to a guest, defaulting to the latest version of the PSCI
implementation that is compatible with the requested version. This is
no different from doing a firmware upgrade on KVM.

But in order to give a chance to hypothetical badly implemented guests
that would have a fit by discovering something other than PSCI 0.2,
let's provide a new API that allows userspace to pick one particular
version of the API.

This is implemented as a new class of "firmware" registers, where
we expose the PSCI version. This allows the PSCI version to be
save/restored as part of a guest migration, and also set to
any supported version if the guest requires it.

Cc: stable@vger.kernel.org #4.16
Reviewed-by: Christoffer Dall &lt;cdall@kernel.org&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>KVM: x86: Add a framework for supporting MSR-based features</title>
<updated>2018-03-01T18:00:28Z</updated>
<author>
<name>Tom Lendacky</name>
</author>
<published>2018-02-21T19:39:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=801e459a6f3a63af9d447e6249088c76ae16efc4'/>
<id>urn:sha1:801e459a6f3a63af9d447e6249088c76ae16efc4</id>
<content type='text'>
Provide a new KVM capability that allows bits within MSRs to be recognized
as features.  Two new ioctls are added to the /dev/kvm ioctl routine to
retrieve the list of these MSRs and then retrieve their values. A kvm_x86_ops
callback is used to determine support for the listed MSR-based features.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
[Tweaked documentation. - Radim]
Signed-off-by: Radim Krčmář &lt;rkrcmar@redhat.com&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:07Z</updated>
<author>
<name>Radim Krčmář</name>
</author>
<published>2018-02-01T15:13:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.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:17Z</updated>
<author>
<name>Radim Krčmář</name>
</author>
<published>2018-02-01T14:04:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.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:01Z</updated>
<author>
<name>Paul Mackerras</name>
</author>
<published>2018-01-15T05:06:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.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 branch 'sev-v9-p2' of https://github.com/codomania/kvm</title>
<updated>2018-01-16T15:35:32Z</updated>
<author>
<name>Paolo Bonzini</name>
</author>
<published>2018-01-16T15:34:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=65e38583c3bbbba78a081c808e2d58a8454a821e'/>
<id>urn:sha1:65e38583c3bbbba78a081c808e2d58a8454a821e</id>
<content type='text'>
This part of Secure Encrypted Virtualization (SEV) patch series focuses on KVM
changes required to create and manage SEV guests.

SEV is an extension to the AMD-V architecture which supports running encrypted
virtual machine (VMs) under the control of a hypervisor. Encrypted VMs have their
pages (code and data) secured such that only the guest itself has access to
unencrypted version. Each encrypted VM is associated with a unique encryption key;
if its data is accessed to a different entity using a different key the encrypted
guest's data will be incorrectly decrypted, leading to unintelligible data.
This security model ensures that hypervisor will no longer able to inspect or
alter any guest code or data.

The key management of this feature is handled by a separate processor known as
the AMD Secure Processor (AMD-SP) which is present on AMD SOCs. The SEV Key
Management Specification (see below) provides a set of commands which can be
used by hypervisor to load virtual machine keys through the AMD-SP driver.

The patch series adds a new ioctl in KVM driver (KVM_MEMORY_ENCRYPT_OP). The
ioctl will be used by qemu to issue SEV guest-specific commands defined in Key
Management Specification.

The following links provide additional details:

AMD Memory Encryption white paper:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer's Manual:
    http://support.amd.com/TechDocs/24593.pdf
    SME is section 7.10
    SEV is section 15.34

SEV Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf

KVM Forum Presentation:
http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf

SEV Guest BIOS support:
  SEV support has been add to EDKII/OVMF BIOS
  https://github.com/tianocore/edk2

Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S HV: Enable migration of decrementer register</title>
<updated>2018-01-16T00:54:45Z</updated>
<author>
<name>Paul Mackerras</name>
</author>
<published>2018-01-12T09:55:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.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>
<entry>
<title>KVM: s390: mark irq_state.flags as non-usable</title>
<updated>2017-12-06T08:18:43Z</updated>
<author>
<name>Christian Borntraeger</name>
</author>
<published>2017-11-21T15:02:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bb64da9aba89765fee74b395967b18a7d6c364e9'/>
<id>urn:sha1:bb64da9aba89765fee74b395967b18a7d6c364e9</id>
<content type='text'>
Old kernels did not check for zero in the irq_state.flags field and old
QEMUs did not zero the flag/reserved fields when calling
KVM_S390_*_IRQ_STATE.  Let's add comments to prevent future uses of
these fields.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Reviewed-by: Thomas Huth &lt;thuth@redhat.com&gt;
Reviewed-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Reviewed-by: David Hildenbrand &lt;david@redhat.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl</title>
<updated>2017-12-04T16:57:26Z</updated>
<author>
<name>Brijesh Singh</name>
</author>
<published>2017-12-04T16:57:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=69eaedee411c1fc1cf123520897a96b7cf04d8a0'/>
<id>urn:sha1:69eaedee411c1fc1cf123520897a96b7cf04d8a0</id>
<content type='text'>
If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_REG_REGION
and KVM_MEMORY_ENCRYPT_UNREG_REGION ioctl's can be used by userspace to
register/unregister the guest memory regions which may contain the encrypted
data (e.g guest RAM, PCI BAR, SMRAM etc).

Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim Krčmář" &lt;rkrcmar@redhat.com&gt;
Cc: Joerg Roedel &lt;joro@8bytes.org&gt;
Cc: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Improvements-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Reviewed-by: Borislav Petkov &lt;bp@suse.de&gt;
</content>
</entry>
<entry>
<title>KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl</title>
<updated>2017-12-04T16:57:26Z</updated>
<author>
<name>Brijesh Singh</name>
</author>
<published>2017-12-04T16:57:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5acc5c063196b4a531a761a954023c1848ec832b'/>
<id>urn:sha1:5acc5c063196b4a531a761a954023c1848ec832b</id>
<content type='text'>
If the hardware supports memory encryption then the
KVM_MEMORY_ENCRYPT_OP ioctl can be used by qemu to issue a platform
specific memory encryption commands.

Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: "Radim Krčmář" &lt;rkrcmar@redhat.com&gt;
Cc: Joerg Roedel &lt;joro@8bytes.org&gt;
Cc: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
Reviewed-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Reviewed-by: Borislav Petkov &lt;bp@suse.de&gt;
</content>
</entry>
</feed>
