<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/Documentation/virtual, branch dev-4.7</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.7</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.7'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2016-10-16T15:50:37+00:00</updated>
<entry>
<title>KVM: arm64: Require in-kernel irqchip for PMU support</title>
<updated>2016-10-16T15:50:37+00:00</updated>
<author>
<name>Christoffer Dall</name>
<email>christoffer.dall@linaro.org</email>
</author>
<published>2016-09-27T01:51:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6b30b92d592f7da0e1a653dc951479cff43fd82b'/>
<id>urn:sha1:6b30b92d592f7da0e1a653dc951479cff43fd82b</id>
<content type='text'>
commit 6fe407f2d18a4f94216263f91cb7d1f08fa5887c upstream.

If userspace creates a PMU for the VCPU, but doesn't create an in-kernel
irqchip, then we end up in a nasty path where we try to take an
uninitialized spinlock, which can lead to all sorts of breakages.

Luckily, QEMU always creates the VGIC before the PMU, so we can
establish this as ABI and check for the VGIC in the PMU init stage.
This can be relaxed at a later time if we want to support PMU with a
userspace irqchip.

Cc: Shannon Zhao &lt;shannon.zhao@linaro.org&gt;
Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kvm: introduce KVM_MAX_VCPU_ID</title>
<updated>2016-05-11T20:37:54+00:00</updated>
<author>
<name>Greg Kurz</name>
<email>gkurz@linux.vnet.ibm.com</email>
</author>
<published>2016-05-09T16:13:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0b1b1dfd52a67f4f09a18cb82337199bc90ad7fb'/>
<id>urn:sha1:0b1b1dfd52a67f4f09a18cb82337199bc90ad7fb</id>
<content type='text'>
The KVM_MAX_VCPUS define provides the maximum number of vCPUs per guest, and
also the upper limit for vCPU ids. This is okay for all archs except PowerPC
which can have higher ids, depending on the cpu/core/thread topology. In the
worst case (single threaded guest, host with 8 threads per core), it limits
the maximum number of vCPUS to KVM_MAX_VCPUS / 8.

This patch separates the vCPU numbering from the total number of vCPUs, with
the introduction of KVM_MAX_VCPU_ID, as the maximal valid value for vCPU ids
plus one.

The corresponding KVM_CAP_MAX_VCPU_ID allows userspace to validate vCPU ids
before passing them to KVM_CREATE_VCPU.

This patch only implements KVM_MAX_VCPU_ID with a specific value for PowerPC.
Other archs continue to return KVM_MAX_VCPUS instead.

Suggested-by: Radim Krcmar &lt;rkrcmar@redhat.com&gt;
Signed-off-by: Greg Kurz &lt;gkurz@linux.vnet.ibm.com&gt;
Reviewed-by: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'kvm-s390-next-4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD</title>
<updated>2016-05-10T14:37:38+00:00</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2016-05-10T14:37:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6ac0f61f47a24bad3fa99ee6a46c0cc5a245ee91'/>
<id>urn:sha1:6ac0f61f47a24bad3fa99ee6a46c0cc5a245ee91</id>
<content type='text'>
KVM: s390: features and fixes for 4.7 part2

- Use hardware provided information about facility bits that do not
  need any hypervisor activitiy
- Add missing documentation for KVM_CAP_S390_RI
- Some updates/fixes for handling cpu models and facilities
</content>
</entry>
<entry>
<title>KVM: s390: document KVM_CAP_S390_RI</title>
<updated>2016-05-09T11:33:58+00:00</updated>
<author>
<name>David Hildenbrand</name>
<email>dahi@linux.vnet.ibm.com</email>
</author>
<published>2016-04-19T11:13:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=051c87f744a21b866872b16821084e96794231b5'/>
<id>urn:sha1:051c87f744a21b866872b16821084e96794231b5</id>
<content type='text'>
We forgot to document that capability, let's add documentation.

Reviewed-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: David Hildenbrand &lt;dahi@linux.vnet.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>Documentation: virtual: fix spelling mistake</title>
<updated>2016-04-25T14:59:49+00:00</updated>
<author>
<name>Eric Engestrom</name>
<email>eric@engestrom.ch</email>
</author>
<published>2016-04-25T06:37:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1f644a737340592a7c20a7c525e8d279e9a4f119'/>
<id>urn:sha1:1f644a737340592a7c20a7c525e8d279e9a4f119</id>
<content type='text'>
Signed-off-by: Eric Engestrom &lt;eric@engestrom.ch&gt;
Acked-by: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Signed-off-by: Radim Krčmář &lt;rkrcmar@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: s390: add clear I/O irq operation for FLIC</title>
<updated>2016-04-20T12:27:32+00:00</updated>
<author>
<name>Halil Pasic</name>
<email>pasic@linux.vnet.ibm.com</email>
</author>
<published>2016-01-25T18:10:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6d28f789bf81540d4069342b1a28bfd41dab38a3'/>
<id>urn:sha1:6d28f789bf81540d4069342b1a28bfd41dab38a3</id>
<content type='text'>
Introduce a FLIC operation for clearing I/O interrupts for a subchannel.

Rationale: According to the platform specification, pending I/O
interruption requests have to be revoked in certain situations. For
instance, according to the Principles of Operation (page 17-27), a
subchannel put into the installed parameters initialized state is in the
same state as after an I/O system reset (just parameters possibly changed).
This implies that any I/O interrupts for that subchannel are no longer
pending (as I/O system resets clear I/O interrupts). Therefore, we need an
interface to clear pending I/O interrupts.

Signed-off-by: Halil Pasic &lt;pasic@linux.vnet.ibm.com&gt;
Reviewed-by: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Reviewed-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>KVM: s390: document FLIC behavior on unsupported</title>
<updated>2016-04-20T12:27:32+00:00</updated>
<author>
<name>Halil Pasic</name>
<email>pasic@linux.vnet.ibm.com</email>
</author>
<published>2016-02-25T12:26:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dad7eefbd048a2f44c990303751159671e988d13'/>
<id>urn:sha1:dad7eefbd048a2f44c990303751159671e988d13</id>
<content type='text'>
FLIC behavior deviates from the API documentation in reporting EINVAL
instead of ENXIO for KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR when the group
or attribute is unknown/unsupported. Unfortunately this can not be fixed
for historical reasons. Let us at least have it documented.

Signed-off-by: Halil Pasic &lt;pasic@linux.vnet.ibm.com&gt;
Reviewed-by: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Reviewed-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm</title>
<updated>2016-03-16T16:55:35+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-03-16T16:55:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=10dc3747661bea9215417b659449bb7b8ed3df2c'/>
<id>urn:sha1:10dc3747661bea9215417b659449bb7b8ed3df2c</id>
<content type='text'>
Pull KVM updates from Paolo Bonzini:
 "One of the largest releases for KVM...  Hardly any generic
  changes, but lots of architecture-specific updates.

  ARM:
   - VHE support so that we can run the kernel at EL2 on ARMv8.1 systems
   - PMU support for guests
   - 32bit world switch rewritten in C
   - various optimizations to the vgic save/restore code.

  PPC:
   - enabled KVM-VFIO integration ("VFIO device")
   - optimizations to speed up IPIs between vcpus
   - in-kernel handling of IOMMU hypercalls
   - support for dynamic DMA windows (DDW).

  s390:
   - provide the floating point registers via sync regs;
   - separated instruction vs.  data accesses
   - dirty log improvements for huge guests
   - bugfixes and documentation improvements.

  x86:
   - Hyper-V VMBus hypercall userspace exit
   - alternative implementation of lowest-priority interrupts using
     vector hashing (for better VT-d posted interrupt support)
   - fixed guest debugging with nested virtualizations
   - improved interrupt tracking in the in-kernel IOAPIC
   - generic infrastructure for tracking writes to guest
     memory - currently its only use is to speedup the legacy shadow
     paging (pre-EPT) case, but in the future it will be used for
     virtual GPUs as well
   - much cleanup (LAPIC, kvmclock, MMU, PIT), including ubsan fixes"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (217 commits)
  KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch
  KVM: x86: disable MPX if host did not enable MPX XSAVE features
  arm64: KVM: vgic-v3: Only wipe LRs on vcpu exit
  arm64: KVM: vgic-v3: Reset LRs at boot time
  arm64: KVM: vgic-v3: Do not save an LR known to be empty
  arm64: KVM: vgic-v3: Save maintenance interrupt state only if required
  arm64: KVM: vgic-v3: Avoid accessing ICH registers
  KVM: arm/arm64: vgic-v2: Make GICD_SGIR quicker to hit
  KVM: arm/arm64: vgic-v2: Only wipe LRs on vcpu exit
  KVM: arm/arm64: vgic-v2: Reset LRs at boot time
  KVM: arm/arm64: vgic-v2: Do not save an LR known to be empty
  KVM: arm/arm64: vgic-v2: Move GICH_ELRSR saving to its own function
  KVM: arm/arm64: vgic-v2: Save maintenance interrupt state only if required
  KVM: arm/arm64: vgic-v2: Avoid accessing GICH registers
  KVM: s390: allocate only one DMA page per VM
  KVM: s390: enable STFLE interpretation only if enabled for the guest
  KVM: s390: wake up when the VCPU cpu timer expires
  KVM: s390: step the VCPU timer while in enabled wait
  KVM: s390: protect VCPU cpu timer with a seqcount
  KVM: s390: step VCPU cpu timer during kvm_run ioctl
  ...
</content>
</entry>
<entry>
<title>KVM: MMU: fix ept=0/pte.u=1/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo</title>
<updated>2016-03-10T10:26:07+00:00</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2016-03-08T11:13:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=844a5fe219cf472060315971e15cbf97674a3324'/>
<id>urn:sha1:844a5fe219cf472060315971e15cbf97674a3324</id>
<content type='text'>
Yes, all of these are needed. :) This is admittedly a bit odd, but
kvm-unit-tests access.flat tests this if you run it with "-cpu host"
and of course ept=0.

KVM runs the guest with CR0.WP=1, so it must handle supervisor writes
specially when pte.u=1/pte.w=0/CR0.WP=0.  Such writes cause a fault
when U=1 and W=0 in the SPTE, but they must succeed because CR0.WP=0.
When KVM gets the fault, it sets U=0 and W=1 in the shadow PTE and
restarts execution.  This will still cause a user write to fault, while
supervisor writes will succeed.  User reads will fault spuriously now,
and KVM will then flip U and W again in the SPTE (U=1, W=0).  User reads
will be enabled and supervisor writes disabled, going back to the
originary situation where supervisor writes fault spuriously.

When SMEP is in effect, however, U=0 will enable kernel execution of
this page.  To avoid this, KVM also sets NX=1 in the shadow PTE together
with U=0.  If the guest has not enabled NX, the result is a continuous
stream of page faults due to the NX bit being reserved.

The fix is to force EFER.NX=1 even if the CPU is taking care of the EFER
switch.  (All machines with SMEP have the CPU_LOAD_IA32_EFER vm-entry
control, so they do not use user-return notifiers for EFER---if they did,
EFER.NX would be forced to the same value as the host).

There is another bug in the reserved bit check, which I've split to a
separate patch for easier application to stable kernels.

Cc: stable@vger.kernel.org
Cc: Andy Lutomirski &lt;luto@amacapital.net&gt;
Reviewed-by: Xiao Guangrong &lt;guangrong.xiao@linux.intel.com&gt;
Fixes: f6577a5fa15d82217ca73c74cd2dcbc0f6c781dd
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'kvm-arm-for-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD</title>
<updated>2016-03-09T10:50:42+00:00</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2016-03-09T10:50:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ab92f30875a7ec3e84644a5494febd8901e66742'/>
<id>urn:sha1:ab92f30875a7ec3e84644a5494febd8901e66742</id>
<content type='text'>
KVM/ARM updates for 4.6

- VHE support so that we can run the kernel at EL2 on ARMv8.1 systems
- PMU support for guests
- 32bit world switch rewritten in C
- Various optimizations to the vgic save/restore code

Conflicts:
	include/uapi/linux/kvm.h
</content>
</entry>
</feed>
