linux-next: manual merge of the kvm tree with Linus' tree

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/vmx.c

between a series of commits in Linus' tree and a series of commits in
the kvm tree.

I have no idea how to fix all this up, so I just dropped all the changes
from Linus' tree (all those commits only touched this file).  Please do
this merge your self or provide me (and Linus) with the necessary
resolution.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Rebasing kvm/next (was Re: linux-next: manual merge of the kvm tree with Linus' tree)

[Paolo Bonzini]

[-- Attachment #1.1: Type: text/plain, Size: 882 bytes --]

On 06/08/2018 07:21, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/vmx.c
> 
> between a series of commits in Linus' tree and a series of commits in
> the kvm tree.
> 
> I have no idea how to fix all this up, so I just dropped all the changes
> from Linus' tree (all those commits only touched this file).  Please do
> this merge your self or provide me (and Linus) with the necessary
> resolution.

The conflicts are indeed very nasty, so I'm going to rebase the top of
kvm/next and insert a merge from Linus's tree (4.18-rc6 to be precise).

The reason is that some changes were split between 4.18 and 4.19, and
therefore there are conflicts between bugfixes and new development.
They should have been handled by merging kvm/master into kvm/next, but
it's too late for that.

Paolo


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/riscv/kernel/cpu.c

between commit:

  61a41d16ad20 ("RISC-V: Print SSTC in canonical order")

from Linus' tree and commit:

  122979aa26cd ("RISC-V: Probe Svinval extension form ISA string")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/riscv/kernel/cpu.c
index 87455d12970f,7d1cd653ca02..000000000000
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@@ -96,6 -95,8 +96,7 @@@ static struct riscv_isa_ext_data isa_ex
  	__RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
  	__RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM),
  	__RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
 -	__RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
+ 	__RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
  	__RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
  };
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

On 7/13/22 08:02, Stephen Rothwell wrote:
> I didn't know if the new includes needed to be prefixed with "../"
> as well ... I though it was better safe than sorry.

If it compiles, it's perfect. :)

Thanks, I'll check it out and report to Linus the reason for the conflict.

Paolo

> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/vmx/capabilities.h

between commit:

  07853adc29a0 ("KVM: VMX: Prevent RSB underflow before vmenter")

from Linus' tree and commits:

  cf8e55fe50df ("KVM: x86/pmu: Expose CPUIDs feature bits PDCM, DS, DTES64")
  6ef25aa0a961 ("KVM: x86/pmu: Restrict advanced features based on module enable_pmu")

from the kvm tree.

I didn't know if the new includes needed to be prefixed with "../"
as well ... I though it was better safe than sorry.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx/capabilities.h
index c0e24826a86f,069d8d298e1d..000000000000
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@@ -4,8 -4,10 +4,10 @@@
  
  #include <asm/vmx.h>
  
 -#include "lapic.h"
 -#include "x86.h"
 -#include "pmu.h"
 -#include "cpuid.h"
 +#include "../lapic.h"
 +#include "../x86.h"
++#include "../pmu.h"
++#include "../cpuid.h"
  
  extern bool __read_mostly enable_vpid;
  extern bool __read_mostly flexpriority_enabled;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/x86.c

between commit:

  6cd88243c7e0 ("KVM: x86: do not report a vCPU as preempted outside instruction boundaries")

from Linus' tree and commit:

  2f4073e08f4c ("KVM: VMX: Enable Notify VM exit")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/x86.c
index 2ec6a110ec6c,79efdc19b4c8..000000000000
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@@ -296,9 -284,8 +284,10 @@@ const struct _kvm_stats_desc kvm_vcpu_s
  	STATS_DESC_COUNTER(VCPU, nested_run),
  	STATS_DESC_COUNTER(VCPU, directed_yield_attempted),
  	STATS_DESC_COUNTER(VCPU, directed_yield_successful),
 +	STATS_DESC_COUNTER(VCPU, preemption_reported),
 +	STATS_DESC_COUNTER(VCPU, preemption_other),
- 	STATS_DESC_ICOUNTER(VCPU, guest_mode)
+ 	STATS_DESC_ICOUNTER(VCPU, guest_mode),
+ 	STATS_DESC_COUNTER(VCPU, notify_window_exits),
  };
  
  const struct kvm_stats_header kvm_vcpu_stats_header = {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/pmu.h

between commit:

  75189d1de1b3 ("KVM: x86/pmu: Update AMD PMC sample period to fix guest NMI-watchdog")

from Linus' tree and commits:

  a10cabf6815c ("KVM: x86/pmu: Move pmc_speculative_in_use() to arch/x86/kvm/pmu.h")
  8eeac7e999e8 ("KVM: x86/pmu: Add kvm_pmu_cap to optimize perf_get_x86_pmu_capability")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/pmu.h
index 22992b049d38,dbf4c83519a4..000000000000
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@@ -138,15 -143,35 +143,44 @@@ static inline u64 get_sample_period(str
  	return sample_period;
  }
  
 +static inline void pmc_update_sample_period(struct kvm_pmc *pmc)
 +{
 +	if (!pmc->perf_event || pmc->is_paused)
 +		return;
 +
 +	perf_event_period(pmc->perf_event,
 +			  get_sample_period(pmc, pmc->counter));
 +}
 +
+ static inline bool pmc_speculative_in_use(struct kvm_pmc *pmc)
+ {
+ 	struct kvm_pmu *pmu = pmc_to_pmu(pmc);
+ 
+ 	if (pmc_is_fixed(pmc))
+ 		return fixed_ctrl_field(pmu->fixed_ctr_ctrl,
+ 					pmc->idx - INTEL_PMC_IDX_FIXED) & 0x3;
+ 
+ 	return pmc->eventsel & ARCH_PERFMON_EVENTSEL_ENABLE;
+ }
+ 
+ extern struct x86_pmu_capability kvm_pmu_cap;
+ 
+ static inline void kvm_init_pmu_capability(void)
+ {
+ 	perf_get_x86_pmu_capability(&kvm_pmu_cap);
+ 
+ 	/*
+ 	 * Only support guest architectural pmu on
+ 	 * a host with architectural pmu.
+ 	 */
+ 	if (!kvm_pmu_cap.version)
+ 		memset(&kvm_pmu_cap, 0, sizeof(kvm_pmu_cap));
+ 
+ 	kvm_pmu_cap.version = min(kvm_pmu_cap.version, 2);
+ 	kvm_pmu_cap.num_counters_fixed = min(kvm_pmu_cap.num_counters_fixed,
+ 					     KVM_PMC_MAX_FIXED);
+ }
+ 
  void reprogram_gp_counter(struct kvm_pmc *pmc, u64 eventsel);
  void reprogram_fixed_counter(struct kvm_pmc *pmc, u8 ctrl, int fixed_idx);
  void reprogram_counter(struct kvm_pmu *pmu, int pmc_idx);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kernel/kvm.c

between commit:

  c3b037917c6a ("x86/ibt,paravirt: Sprinkle ENDBR")

from Linus' tree and commit:

  8c5649e00e00 ("KVM: x86: Support the vCPU preemption check with nopvspin and realtime hint")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kernel/kvm.c
index 79e0b8d63ffa,21933095a10e..000000000000
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@@ -752,6 -752,39 +752,40 @@@ static void kvm_crash_shutdown(struct p
  }
  #endif
  
+ #ifdef CONFIG_X86_32
+ __visible bool __kvm_vcpu_is_preempted(long cpu)
+ {
+ 	struct kvm_steal_time *src = &per_cpu(steal_time, cpu);
+ 
+ 	return !!(src->preempted & KVM_VCPU_PREEMPTED);
+ }
+ PV_CALLEE_SAVE_REGS_THUNK(__kvm_vcpu_is_preempted);
+ 
+ #else
+ 
+ #include <asm/asm-offsets.h>
+ 
+ extern bool __raw_callee_save___kvm_vcpu_is_preempted(long);
+ 
+ /*
+  * Hand-optimize version for x86-64 to avoid 8 64-bit register saving and
+  * restoring to/from the stack.
+  */
+ asm(
+ ".pushsection .text;"
+ ".global __raw_callee_save___kvm_vcpu_is_preempted;"
+ ".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
+ "__raw_callee_save___kvm_vcpu_is_preempted:"
++ASM_ENDBR
+ "movq	__per_cpu_offset(,%rdi,8), %rax;"
+ "cmpb	$0, " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rax);"
+ "setne	%al;"
 -"ret;"
++ASM_RET
+ ".size __raw_callee_save___kvm_vcpu_is_preempted, .-__raw_callee_save___kvm_vcpu_is_preempted;"
+ ".popsection");
+ 
+ #endif
+ 
  static void __init kvm_guest_init(void)
  {
  	int i;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 6761 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  Documentation/virt/kvm/api.rst

between commit:

  b318e8decf6b ("KVM: x86: Protect userspace MSR filter with SRCU, and set atomically-ish")

from Linus tree and commit:

  24e7475f931a ("doc/virt/kvm: move KVM_CAP_PPC_MULTITCE in section 8")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/virt/kvm/api.rst
index 245d80581f15,fd4a84911355..000000000000
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@@ -3690,31 -3692,105 +3693,107 @@@ which is the maximum number of possibl
  
  Queues an SMI on the thread's vcpu.
  
- 4.97 KVM_CAP_PPC_MULTITCE
- -------------------------
+ 4.97 KVM_X86_SET_MSR_FILTER
+ ----------------------------
  
- :Capability: KVM_CAP_PPC_MULTITCE
- :Architectures: ppc
- :Type: vm
+ :Capability: KVM_X86_SET_MSR_FILTER
+ :Architectures: x86
+ :Type: vm ioctl
+ :Parameters: struct kvm_msr_filter
+ :Returns: 0 on success, < 0 on error
  
- This capability means the kernel is capable of handling hypercalls
- H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user
- space. This significantly accelerates DMA operations for PPC KVM guests.
- User space should expect that its handlers for these hypercalls
- are not going to be called if user space previously registered LIOBN
- in KVM (via KVM_CREATE_SPAPR_TCE or similar calls).
+ ::
  
- In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest,
- user space might have to advertise it for the guest. For example,
- IBM pSeries (sPAPR) guest starts using them if "hcall-multi-tce" is
- present in the "ibm,hypertas-functions" device-tree property.
+   struct kvm_msr_filter_range {
+   #define KVM_MSR_FILTER_READ  (1 << 0)
+   #define KVM_MSR_FILTER_WRITE (1 << 1)
+ 	__u32 flags;
+ 	__u32 nmsrs; /* number of msrs in bitmap */
+ 	__u32 base;  /* MSR index the bitmap starts at */
+ 	__u8 *bitmap; /* a 1 bit allows the operations in flags, 0 denies */
+   };
  
- The hypercalls mentioned above may or may not be processed successfully
- in the kernel based fast path. If they can not be handled by the kernel,
- they will get passed on to user space. So user space still has to have
- an implementation for these despite the in kernel acceleration.
+   #define KVM_MSR_FILTER_MAX_RANGES 16
+   struct kvm_msr_filter {
+   #define KVM_MSR_FILTER_DEFAULT_ALLOW (0 << 0)
+   #define KVM_MSR_FILTER_DEFAULT_DENY  (1 << 0)
+ 	__u32 flags;
+ 	struct kvm_msr_filter_range ranges[KVM_MSR_FILTER_MAX_RANGES];
+   };
  
- This capability is always enabled.
+ flags values for ``struct kvm_msr_filter_range``:
+ 
+ ``KVM_MSR_FILTER_READ``
+ 
+   Filter read accesses to MSRs using the given bitmap. A 0 in the bitmap
+   indicates that a read should immediately fail, while a 1 indicates that
+   a read for a particular MSR should be handled regardless of the default
+   filter action.
+ 
+ ``KVM_MSR_FILTER_WRITE``
+ 
+   Filter write accesses to MSRs using the given bitmap. A 0 in the bitmap
+   indicates that a write should immediately fail, while a 1 indicates that
+   a write for a particular MSR should be handled regardless of the default
+   filter action.
+ 
+ ``KVM_MSR_FILTER_READ | KVM_MSR_FILTER_WRITE``
+ 
+   Filter both read and write accesses to MSRs using the given bitmap. A 0
+   in the bitmap indicates that both reads and writes should immediately fail,
+   while a 1 indicates that reads and writes for a particular MSR are not
+   filtered by this range.
+ 
+ flags values for ``struct kvm_msr_filter``:
+ 
+ ``KVM_MSR_FILTER_DEFAULT_ALLOW``
+ 
+   If no filter range matches an MSR index that is getting accessed, KVM will
+   fall back to allowing access to the MSR.
+ 
+ ``KVM_MSR_FILTER_DEFAULT_DENY``
+ 
+   If no filter range matches an MSR index that is getting accessed, KVM will
+   fall back to rejecting access to the MSR. In this mode, all MSRs that should
+   be processed by KVM need to explicitly be marked as allowed in the bitmaps.
+ 
+ This ioctl allows user space to define up to 16 bitmaps of MSR ranges to
+ specify whether a certain MSR access should be explicitly filtered for or not.
+ 
+ If this ioctl has never been invoked, MSR accesses are not guarded and the
+ default KVM in-kernel emulation behavior is fully preserved.
+ 
+ Calling this ioctl with an empty set of ranges (all nmsrs == 0) disables MSR
+ filtering. In that mode, ``KVM_MSR_FILTER_DEFAULT_DENY`` is invalid and causes
+ an error.
+ 
+ As soon as the filtering is in place, every MSR access is processed through
+ the filtering except for accesses to the x2APIC MSRs (from 0x800 to 0x8ff);
+ x2APIC MSRs are always allowed, independent of the ``default_allow`` setting,
+ and their behavior depends on the ``X2APIC_ENABLE`` bit of the APIC base
+ register.
+ 
+ If a bit is within one of the defined ranges, read and write accesses are
+ guarded by the bitmap's value for the MSR index if the kind of access
+ is included in the ``struct kvm_msr_filter_range`` flags.  If no range
+ cover this particular access, the behavior is determined by the flags
+ field in the kvm_msr_filter struct: ``KVM_MSR_FILTER_DEFAULT_ALLOW``
+ and ``KVM_MSR_FILTER_DEFAULT_DENY``.
+ 
+ Each bitmap range specifies a range of MSRs to potentially allow access on.
+ The range goes from MSR index [base .. base+nmsrs]. The flags field
+ indicates whether reads, writes or both reads and writes are filtered
+ by setting a 1 bit in the bitmap for the corresponding MSR index.
+ 
+ If an MSR access is not permitted through the filtering, it generates a
+ #GP inside the guest. When combined with KVM_CAP_X86_USER_SPACE_MSR, that
+ allows user space to deflect and potentially handle various MSR accesses
+ into user space.
+ 
 -If a vCPU is in running state while this ioctl is invoked, the vCPU may
 -experience inconsistent filtering behavior on MSR accesses.
++Note, invoking this ioctl with a vCPU is running is inherently racy.  However,
++KVM does guarantee that vCPUs will see either the previous filter or the new
++filter, e.g. MSRs with identical settings in both the old and new filter will
++have deterministic behavior.
  
  4.98 KVM_CREATE_SPAPR_TCE_64
  ----------------------------

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/svm/svm.c

between commit:

  054409ab253d ("KVM: SVM: fix error return code in svm_create_vcpu()")

from Linus' tree and commit:

  add5e2f04541 ("KVM: SVM: Add support for the SEV-ES VMSA")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/svm/svm.c
index da7eb4aaf44f,941e5251e13f..000000000000
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@@ -1309,10 -1347,8 +1347,10 @@@ static int svm_create_vcpu(struct kvm_v
  		svm->avic_is_running = true;
  
  	svm->msrpm = svm_vcpu_alloc_msrpm();
 -	if (!svm->msrpm)
 +	if (!svm->msrpm) {
 +		err = -ENOMEM;
- 		goto error_free_vmcb_page;
+ 		goto error_free_vmsa_page;
 +	}
  
  	svm_vcpu_init_msrpm(vcpu, svm->msrpm);
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

[-- Attachment #1.1: Type: text/plain, Size: 4319 bytes --]

On 02/04/20 04:36, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/svm/svm.c
> 
> between commits:
> 
>   aaca21007ba1 ("KVM: SVM: Fix the svm vmexit code for WRMSR")
>   2da1ed62d55c ("KVM: SVM: document KVM_MEM_ENCRYPT_OP, let userspace detect if SEV is available")
>   2e2409afe5f0 ("KVM: SVM: Issue WBINVD after deactivating an SEV guest")
> 
> from Linus' tree and commits:
> 
>   83a2c705f002 ("kVM SVM: Move SVM related files to own sub-directory")
>   41f08f0506c0 ("KVM: SVM: Move SEV code to separate file")
> 
> (at least)
> 
> from the kvm tree.
> 
> Its a bit of a pain this code movement appearing during the merge
> window.  Is it really intended for v5.7?

I'll send two separate pull requests to Linus so that he doesn't see the
issues introduced by the code movement.

Paolo

> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 621a36702636..2be5bbae3a40 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -34,6 +34,7 @@
>  #include <asm/kvm_para.h>
>  #include <asm/irq_remapping.h>
>  #include <asm/spec-ctrl.h>
> +#include <asm/cpu_device_id.h>
>  
>  #include <asm/virtext.h>
>  #include "trace.h"
> @@ -47,7 +48,7 @@ MODULE_LICENSE("GPL");
>  
>  #ifdef MODULE
>  static const struct x86_cpu_id svm_cpu_id[] = {
> -	X86_FEATURE_MATCH(X86_FEATURE_SVM),
> +	X86_MATCH_FEATURE(X86_FEATURE_SVM, NULL),
>  	{}
>  };
>  MODULE_DEVICE_TABLE(x86cpu, svm_cpu_id);
> @@ -3715,7 +3716,8 @@ static void svm_handle_exit_irqoff(struct kvm_vcpu *vcpu,
>  	enum exit_fastpath_completion *exit_fastpath)
>  {
>  	if (!is_guest_mode(vcpu) &&
> -		to_svm(vcpu)->vmcb->control.exit_code == EXIT_REASON_MSR_WRITE)
> +	    to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_MSR &&
> +	    to_svm(vcpu)->vmcb->control.exit_info_1)
>  		*exit_fastpath = handle_fastpath_set_msr_irqoff(vcpu);
>  }
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 3ef57dee48cc..0e3fc311d7da 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -920,6 +920,9 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
>  	if (!svm_sev_enabled())
>  		return -ENOTTY;
>  
> +	if (!argp)
> +		return 0;
> +
>  	if (copy_from_user(&sev_cmd, argp, sizeof(struct kvm_sev_cmd)))
>  		return -EFAULT;
>  
> @@ -1030,14 +1033,6 @@ find_enc_region(struct kvm *kvm, struct kvm_enc_region *range)
>  static void __unregister_enc_region_locked(struct kvm *kvm,
>  					   struct enc_region *region)
>  {
> -	/*
> -	 * The guest may change the memory encryption attribute from C=0 -> C=1
> -	 * or vice versa for this memory range. Lets make sure caches are
> -	 * flushed to ensure that guest data gets written into memory with
> -	 * correct C-bit.
> -	 */
> -	sev_clflush_pages(region->pages, region->npages);
> -
>  	sev_unpin_memory(kvm, region->pages, region->npages);
>  	list_del(&region->list);
>  	kfree(region);
> @@ -1062,6 +1057,13 @@ int svm_unregister_enc_region(struct kvm *kvm,
>  		goto failed;
>  	}
>  
> +	/*
> +	 * Ensure that all guest tagged cache entries are flushed before
> +	 * releasing the pages back to the system for use. CLFLUSH will
> +	 * not do this, so issue a WBINVD.
> +	 */
> +	wbinvd_on_all_cpus();
> +
>  	__unregister_enc_region_locked(kvm, region);
>  
>  	mutex_unlock(&kvm->lock);
> @@ -1083,6 +1085,13 @@ void sev_vm_destroy(struct kvm *kvm)
>  
>  	mutex_lock(&kvm->lock);
>  
> +	/*
> +	 * Ensure that all guest tagged cache entries are flushed before
> +	 * releasing the pages back to the system for use. CLFLUSH will
> +	 * not do this, so issue a WBINVD.
> +	 */
> +	wbinvd_on_all_cpus();
> +
>  	/*
>  	 * if userspace was terminated before unregistering the memory regions
>  	 * then lets unpin all the registered memory.
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

[-- Attachment #1.1: Type: text/plain, Size: 1026 bytes --]

On 02/04/20 04:36, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/svm/svm.c
> 
> between commits:
> 
>   aaca21007ba1 ("KVM: SVM: Fix the svm vmexit code for WRMSR")
>   2da1ed62d55c ("KVM: SVM: document KVM_MEM_ENCRYPT_OP, let userspace detect if SEV is available")
>   2e2409afe5f0 ("KVM: SVM: Issue WBINVD after deactivating an SEV guest")
> 
> from Linus' tree and commits:
> 
>   83a2c705f002 ("kVM SVM: Move SVM related files to own sub-directory")
>   41f08f0506c0 ("KVM: SVM: Move SEV code to separate file")
> 
> (at least)
> 
> from the kvm tree.
> 
> Its a bit of a pain this code movement appearing during the merge
> window.  Is it really intended for v5.7?

Yes, it's just due to code movement (a file was split, which I left last
to avoid pain for contributors and minimal room for regressions).
Unfortunately, git ends up being confused, but "git merge -X histogram"
actually does the right thing.

Paolo


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3952 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/svm/svm.c

between commits:

  aaca21007ba1 ("KVM: SVM: Fix the svm vmexit code for WRMSR")
  2da1ed62d55c ("KVM: SVM: document KVM_MEM_ENCRYPT_OP, let userspace detect if SEV is available")
  2e2409afe5f0 ("KVM: SVM: Issue WBINVD after deactivating an SEV guest")

from Linus' tree and commits:

  83a2c705f002 ("kVM SVM: Move SVM related files to own sub-directory")
  41f08f0506c0 ("KVM: SVM: Move SEV code to separate file")

(at least)

from the kvm tree.

Its a bit of a pain this code movement appearing during the merge
window.  Is it really intended for v5.7?

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 621a36702636..2be5bbae3a40 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -34,6 +34,7 @@
 #include <asm/kvm_para.h>
 #include <asm/irq_remapping.h>
 #include <asm/spec-ctrl.h>
+#include <asm/cpu_device_id.h>
 
 #include <asm/virtext.h>
 #include "trace.h"
@@ -47,7 +48,7 @@ MODULE_LICENSE("GPL");
 
 #ifdef MODULE
 static const struct x86_cpu_id svm_cpu_id[] = {
-	X86_FEATURE_MATCH(X86_FEATURE_SVM),
+	X86_MATCH_FEATURE(X86_FEATURE_SVM, NULL),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, svm_cpu_id);
@@ -3715,7 +3716,8 @@ static void svm_handle_exit_irqoff(struct kvm_vcpu *vcpu,
 	enum exit_fastpath_completion *exit_fastpath)
 {
 	if (!is_guest_mode(vcpu) &&
-		to_svm(vcpu)->vmcb->control.exit_code == EXIT_REASON_MSR_WRITE)
+	    to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_MSR &&
+	    to_svm(vcpu)->vmcb->control.exit_info_1)
 		*exit_fastpath = handle_fastpath_set_msr_irqoff(vcpu);
 }

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 3ef57dee48cc..0e3fc311d7da 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -920,6 +920,9 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	if (!svm_sev_enabled())
 		return -ENOTTY;
 
+	if (!argp)
+		return 0;
+
 	if (copy_from_user(&sev_cmd, argp, sizeof(struct kvm_sev_cmd)))
 		return -EFAULT;
 
@@ -1030,14 +1033,6 @@ find_enc_region(struct kvm *kvm, struct kvm_enc_region *range)
 static void __unregister_enc_region_locked(struct kvm *kvm,
 					   struct enc_region *region)
 {
-	/*
-	 * The guest may change the memory encryption attribute from C=0 -> C=1
-	 * or vice versa for this memory range. Lets make sure caches are
-	 * flushed to ensure that guest data gets written into memory with
-	 * correct C-bit.
-	 */
-	sev_clflush_pages(region->pages, region->npages);
-
 	sev_unpin_memory(kvm, region->pages, region->npages);
 	list_del(&region->list);
 	kfree(region);
@@ -1062,6 +1057,13 @@ int svm_unregister_enc_region(struct kvm *kvm,
 		goto failed;
 	}
 
+	/*
+	 * Ensure that all guest tagged cache entries are flushed before
+	 * releasing the pages back to the system for use. CLFLUSH will
+	 * not do this, so issue a WBINVD.
+	 */
+	wbinvd_on_all_cpus();
+
 	__unregister_enc_region_locked(kvm, region);
 
 	mutex_unlock(&kvm->lock);
@@ -1083,6 +1085,13 @@ void sev_vm_destroy(struct kvm *kvm)
 
 	mutex_lock(&kvm->lock);
 
+	/*
+	 * Ensure that all guest tagged cache entries are flushed before
+	 * releasing the pages back to the system for use. CLFLUSH will
+	 * not do this, so issue a WBINVD.
+	 */
+	wbinvd_on_all_cpus();
+
 	/*
 	 * if userspace was terminated before unregistering the memory regions
 	 * then lets unpin all the registered memory.
-- 
2.25.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  mm/huge_memory.c

between commit:

  97d3d0f9a1cf ("mm/huge_memory.c: thp: fix conflict of above-47bit hint address and PMD alignment")

from Linus' tree and commit:

  0638468d2282 ("mm: thp: KVM: Explicitly check for THP when populating secondary MMU")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/huge_memory.c
index a88093213674,9b3ee79d0edf..000000000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -527,13 -527,24 +527,24 @@@ void prep_transhuge_page(struct page *p
  	set_compound_page_dtor(page, TRANSHUGE_PAGE_DTOR);
  }
  
+ bool is_transparent_hugepage(struct page *page)
+ {
+ 	if (!PageCompound(page))
+ 		return 0;
+ 
+ 	page = compound_head(page);
+ 	return is_huge_zero_page(page) ||
+ 	       page[1].compound_dtor == TRANSHUGE_PAGE_DTOR;
+ }
+ EXPORT_SYMBOL_GPL(is_transparent_hugepage);
+ 
 -static unsigned long __thp_get_unmapped_area(struct file *filp, unsigned long len,
 +static unsigned long __thp_get_unmapped_area(struct file *filp,
 +		unsigned long addr, unsigned long len,
  		loff_t off, unsigned long flags, unsigned long size)
  {
 -	unsigned long addr;
  	loff_t off_end = off + len;
  	loff_t off_align = round_up(off, size);
 -	unsigned long len_pad;
 +	unsigned long len_pad, ret;
  
  	if (off_end <= off_align || (off_end - off_align) < size)
  		return 0;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  tools/testing/selftests/kvm/dirty_log_test.c

between commit:

  76d58e0f07ec ("KVM: fix KVM_CLEAR_DIRTY_LOG for memory slots of unaligned size")

from Linus' tree and commit:

  65c4189de8c1 ("KVM: fix KVM_CLEAR_DIRTY_LOG for memory slots of unaligned size")

from the kvm tree.

I fixed it up (the only difference was a comment, so I just used the
former evrsion) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/paging_tmpl.h

between commit:

  73b0140bf0fe ("mm/gup: change GUP fast to use flags rather than a write 'bool'")

from Linus' tree and commit:

  bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/paging_tmpl.h
index 08715034e315,c40af67d0f44..000000000000
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@@ -140,16 -140,36 +140,36 @@@ static int FNAME(cmpxchg_gpte)(struct k
  	pt_element_t *table;
  	struct page *page;
  
 -	npages = get_user_pages_fast((unsigned long)ptep_user, 1, 1, &page);
 +	npages = get_user_pages_fast((unsigned long)ptep_user, 1, FOLL_WRITE, &page);
- 	/* Check if the user is doing something meaningless. */
- 	if (unlikely(npages != 1))
- 		return -EFAULT;
- 
- 	table = kmap_atomic(page);
- 	ret = CMPXCHG(&table[index], orig_pte, new_pte);
- 	kunmap_atomic(table);
- 
- 	kvm_release_page_dirty(page);
+ 	if (likely(npages == 1)) {
+ 		table = kmap_atomic(page);
+ 		ret = CMPXCHG(&table[index], orig_pte, new_pte);
+ 		kunmap_atomic(table);
+ 
+ 		kvm_release_page_dirty(page);
+ 	} else {
+ 		struct vm_area_struct *vma;
+ 		unsigned long vaddr = (unsigned long)ptep_user & PAGE_MASK;
+ 		unsigned long pfn;
+ 		unsigned long paddr;
+ 
+ 		down_read(&current->mm->mmap_sem);
+ 		vma = find_vma_intersection(current->mm, vaddr, vaddr + PAGE_SIZE);
+ 		if (!vma || !(vma->vm_flags & VM_PFNMAP)) {
+ 			up_read(&current->mm->mmap_sem);
+ 			return -EFAULT;
+ 		}
+ 		pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
+ 		paddr = pfn << PAGE_SHIFT;
+ 		table = memremap(paddr, PAGE_SIZE, MEMREMAP_WB);
+ 		if (!table) {
+ 			up_read(&current->mm->mmap_sem);
+ 			return -EFAULT;
+ 		}
+ 		ret = CMPXCHG(&table[index], orig_pte, new_pte);
+ 		memunmap(table);
+ 		up_read(&current->mm->mmap_sem);
+ 	}
  
  	return (ret != orig_pte);
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  Documentation/virtual/kvm/api.txt

between commit:

  dbcdae185a70 ("Documentation: kvm: fix dirty log ioctl arch lists")

from Linus' tree and commit:

  d7547c55cbe7 ("KVM: Introduce KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/virtual/kvm/api.txt
index 64b38dfcc243,73a501eb9291..000000000000
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -3809,8 -3936,8 +3936,8 @@@ to I/O ports
  
  4.117 KVM_CLEAR_DIRTY_LOG (vm ioctl)
  
- Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT
+ Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2
 -Architectures: x86
 +Architectures: x86, arm, arm64, mips
  Type: vm ioctl
  Parameters: struct kvm_dirty_log (in)
  Returns: 0 on success, -1 on error
@@@ -4798,9 -4968,9 +4968,9 @@@ and injected exceptions
  * For the new DR6 bits, note that bit 16 is set iff the #DB exception
    will clear DR6.RTM.
  
- 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT
+ 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2
  
 -Architectures: all
 +Architectures: x86, arm, arm64, mips
  Parameters: args[0] whether feature should be enabled or not
  
  With this capability enabled, KVM_GET_DIRTY_LOG will not automatically

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  virt/kvm/kvm_main.c

between commit:

  8ed0579c12b2 ("kvm: properly check debugfs dentry before using it")

from Linus' tree and commit:

  b12ce36a43f2 ("kvm: Add memcg accounting to KVM allocations")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc virt/kvm/kvm_main.c
index d237d3350a99,0fb0e9aa0935..000000000000
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@@ -4044,8 -4049,8 +4049,8 @@@ static void kvm_uevent_notify_change(un
  	}
  	add_uevent_var(env, "PID=%d", kvm->userspace_pid);
  
 -	if (kvm->debugfs_dentry) {
 +	if (!IS_ERR_OR_NULL(kvm->debugfs_dentry)) {
- 		char *tmp, *p = kmalloc(PATH_MAX, GFP_KERNEL);
+ 		char *tmp, *p = kmalloc(PATH_MAX, GFP_KERNEL_ACCOUNT);
  
  		if (p) {
  			tmp = dentry_path_raw(kvm->debugfs_dentry, p, PATH_MAX);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/vmx.c

between commit:

  5f8bb004bca4 ("KVM: vmx: hyper-v: don't pass EPT configuration info to vmx_hv_remote_flush_tlb()")

from Linus' tree and commit:

  a5c214dad198 ("KVM/VMX: Change hv flush logic when ept tables are mismatched.")

from the kvm tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index e665aa7167cf,abeeb45d1c33..000000000000
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -1567,19 -1577,15 +1577,19 @@@ static int vmx_hv_remote_flush_tlb(stru
  	if (to_kvm_vmx(kvm)->ept_pointers_match == EPT_POINTERS_CHECK)
  		check_ept_pointer_match(kvm);
  
- 	if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
- 		ret = -ENOTSUPP;
- 		goto out;
- 	}
- 
 +	/*
 +	 * FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE hypercall needs the address of the
 +	 * base of EPT PML4 table, strip off EPT configuration information.
 +	 */
- 	ret = hyperv_flush_guest_mapping(
- 			to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & PAGE_MASK);
+ 	if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
+ 		kvm_for_each_vcpu(i, vcpu, kvm)
+ 			ret |= hyperv_flush_guest_mapping(
 -				to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer);
++				to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer & PAGE_MASK);
+ 	} else {
+ 		ret = hyperv_flush_guest_mapping(
 -				to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
++				to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & PAGE_MASK);
+ 	}
  
- out:
  	spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
  	return ret;
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/include/asm/kvm_host.h

between commit:

  5b76a3cff011 ("KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry")

from Linus' tree and commit:

  4180bf1b655a ("KVM: X86: Implement "send IPI" hypercall")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/kvm_host.h
index acebb808c4b5,c18958ef17d2..000000000000
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@@ -1418,7 -1457,10 +1462,11 @@@ int kvm_cpu_get_interrupt(struct kvm_vc
  void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event);
  void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu);
  
+ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
+     		    unsigned long ipi_bitmap_high, int min,
+ 		    unsigned long icr, int op_64_bit);
+ 
 +u64 kvm_get_arch_capabilities(void);
  void kvm_define_shared_msr(unsigned index, u32 msr);
  int kvm_set_shared_msr(unsigned index, u64 val, u64 mask);
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 8549 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/vmx.c

between commit:

  a399477e52c1 ("x86/KVM/VMX: Add module argument for L1TF mitigation")

from Linus' tree and commit:

  877ad952be3d ("KVM: vmx: Add tlb_remote_flush callback support")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index 46b428c0990e,16f9373c01de..000000000000
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -188,150 -189,12 +189,156 @@@ module_param(ple_window_max, uint, 0444
  
  extern const ulong vmx_return;
  
 +static DEFINE_STATIC_KEY_FALSE(vmx_l1d_should_flush);
 +static DEFINE_STATIC_KEY_FALSE(vmx_l1d_flush_cond);
 +static DEFINE_MUTEX(vmx_l1d_flush_mutex);
 +
 +/* Storage for pre module init parameter parsing */
 +static enum vmx_l1d_flush_state __read_mostly vmentry_l1d_flush_param = VMENTER_L1D_FLUSH_AUTO;
 +
 +static const struct {
 +	const char *option;
 +	enum vmx_l1d_flush_state cmd;
 +} vmentry_l1d_param[] = {
 +	{"auto",	VMENTER_L1D_FLUSH_AUTO},
 +	{"never",	VMENTER_L1D_FLUSH_NEVER},
 +	{"cond",	VMENTER_L1D_FLUSH_COND},
 +	{"always",	VMENTER_L1D_FLUSH_ALWAYS},
 +};
 +
 +#define L1D_CACHE_ORDER 4
 +static void *vmx_l1d_flush_pages;
 +
 +static int vmx_setup_l1d_flush(enum vmx_l1d_flush_state l1tf)
 +{
 +	struct page *page;
 +	unsigned int i;
 +
 +	if (!enable_ept) {
 +		l1tf_vmx_mitigation = VMENTER_L1D_FLUSH_EPT_DISABLED;
 +		return 0;
 +	}
 +
 +       if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) {
 +	       u64 msr;
 +
 +	       rdmsrl(MSR_IA32_ARCH_CAPABILITIES, msr);
 +	       if (msr & ARCH_CAP_SKIP_VMENTRY_L1DFLUSH) {
 +		       l1tf_vmx_mitigation = VMENTER_L1D_FLUSH_NOT_REQUIRED;
 +		       return 0;
 +	       }
 +       }
 +
 +	/* If set to auto use the default l1tf mitigation method */
 +	if (l1tf == VMENTER_L1D_FLUSH_AUTO) {
 +		switch (l1tf_mitigation) {
 +		case L1TF_MITIGATION_OFF:
 +			l1tf = VMENTER_L1D_FLUSH_NEVER;
 +			break;
 +		case L1TF_MITIGATION_FLUSH_NOWARN:
 +		case L1TF_MITIGATION_FLUSH:
 +		case L1TF_MITIGATION_FLUSH_NOSMT:
 +			l1tf = VMENTER_L1D_FLUSH_COND;
 +			break;
 +		case L1TF_MITIGATION_FULL:
 +		case L1TF_MITIGATION_FULL_FORCE:
 +			l1tf = VMENTER_L1D_FLUSH_ALWAYS;
 +			break;
 +		}
 +	} else if (l1tf_mitigation == L1TF_MITIGATION_FULL_FORCE) {
 +		l1tf = VMENTER_L1D_FLUSH_ALWAYS;
 +	}
 +
 +	if (l1tf != VMENTER_L1D_FLUSH_NEVER && !vmx_l1d_flush_pages &&
 +	    !boot_cpu_has(X86_FEATURE_FLUSH_L1D)) {
 +		page = alloc_pages(GFP_KERNEL, L1D_CACHE_ORDER);
 +		if (!page)
 +			return -ENOMEM;
 +		vmx_l1d_flush_pages = page_address(page);
 +
 +		/*
 +		 * Initialize each page with a different pattern in
 +		 * order to protect against KSM in the nested
 +		 * virtualization case.
 +		 */
 +		for (i = 0; i < 1u << L1D_CACHE_ORDER; ++i) {
 +			memset(vmx_l1d_flush_pages + i * PAGE_SIZE, i + 1,
 +			       PAGE_SIZE);
 +		}
 +	}
 +
 +	l1tf_vmx_mitigation = l1tf;
 +
 +	if (l1tf != VMENTER_L1D_FLUSH_NEVER)
 +		static_branch_enable(&vmx_l1d_should_flush);
 +	else
 +		static_branch_disable(&vmx_l1d_should_flush);
 +
 +	if (l1tf == VMENTER_L1D_FLUSH_COND)
 +		static_branch_enable(&vmx_l1d_flush_cond);
 +	else
 +		static_branch_disable(&vmx_l1d_flush_cond);
 +	return 0;
 +}
 +
 +static int vmentry_l1d_flush_parse(const char *s)
 +{
 +	unsigned int i;
 +
 +	if (s) {
 +		for (i = 0; i < ARRAY_SIZE(vmentry_l1d_param); i++) {
 +			if (sysfs_streq(s, vmentry_l1d_param[i].option))
 +				return vmentry_l1d_param[i].cmd;
 +		}
 +	}
 +	return -EINVAL;
 +}
 +
 +static int vmentry_l1d_flush_set(const char *s, const struct kernel_param *kp)
 +{
 +	int l1tf, ret;
 +
 +	if (!boot_cpu_has(X86_BUG_L1TF))
 +		return 0;
 +
 +	l1tf = vmentry_l1d_flush_parse(s);
 +	if (l1tf < 0)
 +		return l1tf;
 +
 +	/*
 +	 * Has vmx_init() run already? If not then this is the pre init
 +	 * parameter parsing. In that case just store the value and let
 +	 * vmx_init() do the proper setup after enable_ept has been
 +	 * established.
 +	 */
 +	if (l1tf_vmx_mitigation == VMENTER_L1D_FLUSH_AUTO) {
 +		vmentry_l1d_flush_param = l1tf;
 +		return 0;
 +	}
 +
 +	mutex_lock(&vmx_l1d_flush_mutex);
 +	ret = vmx_setup_l1d_flush(l1tf);
 +	mutex_unlock(&vmx_l1d_flush_mutex);
 +	return ret;
 +}
 +
 +static int vmentry_l1d_flush_get(char *s, const struct kernel_param *kp)
 +{
 +	return sprintf(s, "%s\n", vmentry_l1d_param[l1tf_vmx_mitigation].option);
 +}
 +
 +static const struct kernel_param_ops vmentry_l1d_flush_ops = {
 +	.set = vmentry_l1d_flush_set,
 +	.get = vmentry_l1d_flush_get,
 +};
 +module_param_cb(vmentry_l1d_flush, &vmentry_l1d_flush_ops, NULL, 0644);
 +
+ enum ept_pointers_status {
+ 	EPT_POINTERS_CHECK = 0,
+ 	EPT_POINTERS_MATCH = 1,
+ 	EPT_POINTERS_MISMATCH = 2
+ };
+ 
  struct kvm_vmx {
  	struct kvm kvm;
  
@@@ -937,21 -828,14 +977,13 @@@ struct vcpu_vmx 
  	 */
  	struct loaded_vmcs    vmcs01;
  	struct loaded_vmcs   *loaded_vmcs;
+ 	struct loaded_vmcs   *loaded_cpu_state;
  	bool                  __launched; /* temporary, used in vmx_vcpu_run */
  	struct msr_autoload {
 -		unsigned nr;
 -		struct vmx_msr_entry guest[NR_AUTOLOAD_MSRS];
 -		struct vmx_msr_entry host[NR_AUTOLOAD_MSRS];
 +		struct vmx_msrs guest;
 +		struct vmx_msrs host;
  	} msr_autoload;
- 	struct {
- 		int           loaded;
- 		u16           fs_sel, gs_sel, ldt_sel;
- #ifdef CONFIG_X86_64
- 		u16           ds_sel, es_sel;
- #endif
- 		int           gs_ldt_reload_needed;
- 		int           fs_reload_needed;
- 		u64           msr_host_bndcfgs;
- 	} host_state;
+ 
  	struct {
  		int vm86_active;
  		ulong save_rflags;
@@@ -10647,37 -10779,12 +11021,39 @@@ free_vcpu
  	return ERR_PTR(err);
  }
  
 +#define L1TF_MSG_SMT "L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.\n"
 +#define L1TF_MSG_L1D "L1TF CPU bug present and virtualization mitigation disabled, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.\n"
 +
  static int vmx_vm_init(struct kvm *kvm)
  {
+ 	spin_lock_init(&to_kvm_vmx(kvm)->ept_pointer_lock);
+ 
  	if (!ple_gap)
  		kvm->arch.pause_in_guest = true;
 +
 +	if (boot_cpu_has(X86_BUG_L1TF) && enable_ept) {
 +		switch (l1tf_mitigation) {
 +		case L1TF_MITIGATION_OFF:
 +		case L1TF_MITIGATION_FLUSH_NOWARN:
 +			/* 'I explicitly don't care' is set */
 +			break;
 +		case L1TF_MITIGATION_FLUSH:
 +		case L1TF_MITIGATION_FLUSH_NOSMT:
 +		case L1TF_MITIGATION_FULL:
 +			/*
 +			 * Warn upon starting the first VM in a potentially
 +			 * insecure environment.
 +			 */
 +			if (cpu_smt_control == CPU_SMT_ENABLED)
 +				pr_warn_once(L1TF_MSG_SMT);
 +			if (l1tf_vmx_mitigation == VMENTER_L1D_FLUSH_NEVER)
 +				pr_warn_once(L1TF_MSG_L1D);
 +			break;
 +		case L1TF_MITIGATION_FULL_FORCE:
 +			/* Flush is enforced */
 +			break;
 +		}
 +	}
  	return 0;
  }
  
@@@ -12164,15 -12375,25 +12644,28 @@@ static int nested_vmx_run(struct kvm_vc
  	 */
  
  	vmx->nested.nested_run_pending = 1;
- 	ret = enter_vmx_non_root_mode(vcpu);
+ 	ret = enter_vmx_non_root_mode(vcpu, &exit_qual);
  	if (ret) {
+ 		nested_vmx_entry_failure(vcpu, vmcs12, ret, exit_qual);
  		vmx->nested.nested_run_pending = 0;
- 		return ret;
+ 		return 1;
  	}
  
 +	/* Hide L1D cache contents from the nested guest.  */
 +	vmx->vcpu.arch.l1tf_flush_l1d = true;
 +
+ 	/*
+ 	 * Must happen outside of enter_vmx_non_root_mode() as it will
+ 	 * also be used as part of restoring nVMX state for
+ 	 * snapshot restore (migration).
+ 	 *
+ 	 * In this flow, it is assumed that vmcs12 cache was
+ 	 * trasferred as part of captured nVMX state and should
+ 	 * therefore not be read from guest memory (which may not
+ 	 * exist on destination host yet).
+ 	 */
+ 	nested_cache_shadow_vmcs12(vcpu, vmcs12);
+ 
  	/*
  	 * If we're entering a halted L2 vcpu and the L2 vcpu won't be woken
  	 * by event injection, halt vcpu.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/hyperv.c

between commit:

  696ca779a928 ("KVM: x86: fix #UD address of failed Hyper-V hypercalls")

from Linus' tree and commit:

  56b9ae78303a ("KVM: x86: hyperv: do rep check for each hypercall separately")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/hyperv.c
index 46ff64da44ca,14e0d0ae4e0a..000000000000
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@@ -1385,8 -1527,8 +1531,7 @@@ int kvm_hv_hypercall(struct kvm_vcpu *v
  		break;
  	}
  
- out:
 -	kvm_hv_hypercall_set_result(vcpu, ret);
 -	return 1;
 +	return kvm_hv_hypercall_complete(vcpu, ret);
  }
  
  void kvm_hv_init_vm(struct kvm *kvm)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/vmx.c

between commit:

  f21f165ef922 ("KVM: VMX: introduce alloc_loaded_vmcs")
  904e14fb7cb9 ("KVM: VMX: make MSR bitmaps per-VCPU")
  15d45071523d ("KVM/x86: Add IBPB support")

from Linus' tree and commit:

  276c796cfef5 ("KVM: nVMX: Add a WARN for freeing a loaded VMCS02")
  8eb73e2d410f ("KVM: VMX: drop I/O permission bitmaps")
  1f6e5b25643e ("KVM: vmx: simplify MSR bitmap setup")
  d7231e75f73f ("KVM: VMX: introduce X2APIC_MSR macro")
  c992384bde84 ("KVM: vmx: speed up MSR bitmap merge")
  276c796cfef5 ("KVM: nVMX: Add a WARN for freeing a loaded VMCS02")

from the kvm tree.

I fixed it up (I have no idea if it is correct - see below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

Its probably worth doing this back merge yourself into a test branch to
show Linus how you think it should be done.
-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index bee4c49f6dd0,bb5b4888505b..000000000000
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -903,18 -856,25 +869,22 @@@ static const unsigned short vmcs_field_
  
  static inline short vmcs_field_to_offset(unsigned long field)
  {
 +	const size_t size = ARRAY_SIZE(vmcs_field_to_offset_table);
 +	unsigned short offset;
+ 	unsigned index;
+ 
+ 	if (field >> 15)
+ 		return -ENOENT;
  
- 	BUILD_BUG_ON(size > SHRT_MAX);
- 	if (field >= size)
+ 	index = ROL16(field, 6);
 -	if (index >= ARRAY_SIZE(vmcs_field_to_offset_table))
++	if (index >= size)
  		return -ENOENT;
  
- 	field = array_index_nospec(field, size);
- 	offset = vmcs_field_to_offset_table[field];
 -	/*
 -	 * FIXME: Mitigation for CVE-2017-5753.  To be replaced with a
 -	 * generic mechanism.
 -	 */
 -	asm("lfence");
 -
 -	if (vmcs_field_to_offset_table[index] == 0)
++	index = array_index_nospec(index, size);
++	offset = vmcs_field_to_offset_table[index];
 +	if (offset == 0)
  		return -ENOENT;
 -
 -	return vmcs_field_to_offset_table[index];
 +	return offset;
  }
  
  static inline struct vmcs12 *get_vmcs12(struct kvm_vcpu *vcpu)
@@@ -957,8 -914,12 +927,6 @@@ static DEFINE_PER_CPU(struct list_head
  static DEFINE_PER_CPU(spinlock_t, blocked_vcpu_on_cpu_lock);
  
  enum {
- 	VMX_IO_BITMAP_A,
- 	VMX_IO_BITMAP_B,
 -	VMX_MSR_BITMAP_LEGACY,
 -	VMX_MSR_BITMAP_LONGMODE,
 -	VMX_MSR_BITMAP_LEGACY_X2APIC_APICV,
 -	VMX_MSR_BITMAP_LONGMODE_X2APIC_APICV,
 -	VMX_MSR_BITMAP_LEGACY_X2APIC,
 -	VMX_MSR_BITMAP_LONGMODE_X2APIC,
  	VMX_VMREAD_BITMAP,
  	VMX_VMWRITE_BITMAP,
  	VMX_BITMAP_NR
@@@ -966,8 -927,12 +934,6 @@@
  
  static unsigned long *vmx_bitmap[VMX_BITMAP_NR];
  
- #define vmx_io_bitmap_a                      (vmx_bitmap[VMX_IO_BITMAP_A])
- #define vmx_io_bitmap_b                      (vmx_bitmap[VMX_IO_BITMAP_B])
 -#define vmx_msr_bitmap_legacy                (vmx_bitmap[VMX_MSR_BITMAP_LEGACY])
 -#define vmx_msr_bitmap_longmode              (vmx_bitmap[VMX_MSR_BITMAP_LONGMODE])
 -#define vmx_msr_bitmap_legacy_x2apic_apicv   (vmx_bitmap[VMX_MSR_BITMAP_LEGACY_X2APIC_APICV])
 -#define vmx_msr_bitmap_longmode_x2apic_apicv (vmx_bitmap[VMX_MSR_BITMAP_LONGMODE_X2APIC_APICV])
 -#define vmx_msr_bitmap_legacy_x2apic         (vmx_bitmap[VMX_MSR_BITMAP_LEGACY_X2APIC])
 -#define vmx_msr_bitmap_longmode_x2apic       (vmx_bitmap[VMX_MSR_BITMAP_LONGMODE_X2APIC])
  #define vmx_vmread_bitmap                    (vmx_bitmap[VMX_VMREAD_BITMAP])
  #define vmx_vmwrite_bitmap                   (vmx_bitmap[VMX_VMWRITE_BITMAP])
  
@@@ -3945,33 -3821,19 +3914,46 @@@ static void free_loaded_vmcs(struct loa
  	WARN_ON(loaded_vmcs->shadow_vmcs != NULL);
  }
  
 +static struct vmcs *alloc_vmcs(void)
 +{
 +	return alloc_vmcs_cpu(raw_smp_processor_id());
 +}
 +
 +static int alloc_loaded_vmcs(struct loaded_vmcs *loaded_vmcs)
 +{
 +	loaded_vmcs->vmcs = alloc_vmcs();
 +	if (!loaded_vmcs->vmcs)
 +		return -ENOMEM;
 +
 +	loaded_vmcs->shadow_vmcs = NULL;
 +	loaded_vmcs_init(loaded_vmcs);
 +
 +	if (cpu_has_vmx_msr_bitmap()) {
 +		loaded_vmcs->msr_bitmap = (unsigned long *)__get_free_page(GFP_KERNEL);
 +		if (!loaded_vmcs->msr_bitmap)
 +			goto out_vmcs;
 +		memset(loaded_vmcs->msr_bitmap, 0xff, PAGE_SIZE);
 +	}
 +	return 0;
 +
 +out_vmcs:
 +	free_loaded_vmcs(loaded_vmcs);
 +	return -ENOMEM;
 +}
 +
+ static void vmx_nested_free_vmcs02(struct vcpu_vmx *vmx)
+ {
+ 	struct loaded_vmcs *loaded_vmcs = &vmx->nested.vmcs02;
+ 
+ 	/*
+ 	 * Just leak the VMCS02 if the WARN triggers. Better than
+ 	 * a use-after-free.
+ 	 */
+ 	if (WARN_ON(vmx->loaded_vmcs == loaded_vmcs))
+ 		return;
+ 	free_loaded_vmcs(loaded_vmcs);
+ }
+ 
  static void free_kvm_area(void)
  {
  	int cpu;
@@@ -6957,10 -6786,9 +6990,6 @@@ static __init int hardware_setup(void
  	memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
  	memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
  
- 	memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE);
- 
- 	memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE);
 -	memset(vmx_msr_bitmap_legacy, 0xff, PAGE_SIZE);
 -	memset(vmx_msr_bitmap_longmode, 0xff, PAGE_SIZE);
--
  	if (setup_vmcs_config(&vmcs_config) < 0) {
  		r = -EIO;
  		goto out;
@@@ -7345,7 -7212,10 +7374,7 @@@ out_shadow_vmcs
  	kfree(vmx->nested.cached_vmcs12);
  
  out_cached_vmcs12:
- 	free_loaded_vmcs(&vmx->nested.vmcs02);
 -	free_page((unsigned long)vmx->nested.msr_bitmap);
 -
 -out_msr_bitmap:
+ 	vmx_nested_free_vmcs02(vmx);
  
  out_vmcs02:
  	return -ENOMEM;
@@@ -10205,70 -10030,56 +10223,84 @@@ static inline bool nested_vmx_prepare_m
  	int msr;
  	struct page *page;
  	unsigned long *msr_bitmap_l1;
 -	unsigned long *msr_bitmap_l0 = to_vmx(vcpu)->nested.msr_bitmap;
 +	unsigned long *msr_bitmap_l0 = to_vmx(vcpu)->nested.vmcs02.msr_bitmap;
 +	/*
 +	 * pred_cmd & spec_ctrl are trying to verify two things:
 +	 *
 +	 * 1. L0 gave a permission to L1 to actually passthrough the MSR. This
 +	 *    ensures that we do not accidentally generate an L02 MSR bitmap
 +	 *    from the L12 MSR bitmap that is too permissive.
 +	 * 2. That L1 or L2s have actually used the MSR. This avoids
 +	 *    unnecessarily merging of the bitmap if the MSR is unused. This
 +	 *    works properly because we only update the L01 MSR bitmap lazily.
 +	 *    So even if L0 should pass L1 these MSRs, the L01 bitmap is only
 +	 *    updated to reflect this when L1 (or its L2s) actually write to
 +	 *    the MSR.
 +	 */
 +	bool pred_cmd = msr_write_intercepted_l01(vcpu, MSR_IA32_PRED_CMD);
 +	bool spec_ctrl = msr_write_intercepted_l01(vcpu, MSR_IA32_SPEC_CTRL);
  
+ 	/* Nothing to do if the MSR bitmap is not in use.  */
+ 	if (!cpu_has_vmx_msr_bitmap() ||
+ 	    !nested_cpu_has(vmcs12, CPU_BASED_USE_MSR_BITMAPS))
+ 		return false;
+ 
 -	/* This shortcut is ok because we support only x2APIC MSRs so far. */
 -	if (!nested_cpu_has_virt_x2apic_mode(vmcs12))
 +	if (!nested_cpu_has_virt_x2apic_mode(vmcs12) &&
 +	    !pred_cmd && !spec_ctrl)
  		return false;
  
  	page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->msr_bitmap);
  	if (is_error_page(page))
  		return false;
+ 
  	msr_bitmap_l1 = (unsigned long *)kmap(page);
+ 	if (nested_cpu_has_apic_reg_virt(vmcs12)) {
+ 		/*
+ 		 * L0 need not intercept reads for MSRs between 0x800 and 0x8ff, it
+ 		 * just lets the processor take the value from the virtual-APIC page;
+ 		 * take those 256 bits directly from the L1 bitmap.
+ 		 */
+ 		for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) {
+ 			unsigned word = msr / BITS_PER_LONG;
+ 			msr_bitmap_l0[word] = msr_bitmap_l1[word];
+ 			msr_bitmap_l0[word + (0x800 / sizeof(long))] = ~0;
+ 		}
+ 	} else {
+ 		for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) {
+ 			unsigned word = msr / BITS_PER_LONG;
+ 			msr_bitmap_l0[word] = ~0;
+ 			msr_bitmap_l0[word + (0x800 / sizeof(long))] = ~0;
+ 		}
+ 	}
  
- 	memset(msr_bitmap_l0, 0xff, PAGE_SIZE);
- 
- 	if (nested_cpu_has_virt_x2apic_mode(vmcs12)) {
- 		if (nested_cpu_has_apic_reg_virt(vmcs12))
- 			for (msr = 0x800; msr <= 0x8ff; msr++)
- 				nested_vmx_disable_intercept_for_msr(
- 					msr_bitmap_l1, msr_bitmap_l0,
- 					msr, MSR_TYPE_R);
+ 	nested_vmx_disable_intercept_for_msr(
+ 		msr_bitmap_l1, msr_bitmap_l0,
+ 		X2APIC_MSR(APIC_TASKPRI),
+ 		MSR_TYPE_W);
  
+ 	if (nested_cpu_has_vid(vmcs12)) {
  		nested_vmx_disable_intercept_for_msr(
- 				msr_bitmap_l1, msr_bitmap_l0,
- 				APIC_BASE_MSR + (APIC_TASKPRI >> 4),
- 				MSR_TYPE_R | MSR_TYPE_W);
- 
- 		if (nested_cpu_has_vid(vmcs12)) {
- 			nested_vmx_disable_intercept_for_msr(
- 				msr_bitmap_l1, msr_bitmap_l0,
- 				APIC_BASE_MSR + (APIC_EOI >> 4),
- 				MSR_TYPE_W);
- 			nested_vmx_disable_intercept_for_msr(
- 				msr_bitmap_l1, msr_bitmap_l0,
- 				APIC_BASE_MSR + (APIC_SELF_IPI >> 4),
- 				MSR_TYPE_W);
- 		}
+ 			msr_bitmap_l1, msr_bitmap_l0,
+ 			X2APIC_MSR(APIC_EOI),
+ 			MSR_TYPE_W);
+ 		nested_vmx_disable_intercept_for_msr(
+ 			msr_bitmap_l1, msr_bitmap_l0,
+ 			X2APIC_MSR(APIC_SELF_IPI),
+ 			MSR_TYPE_W);
  	}
 +
 +	if (spec_ctrl)
 +		nested_vmx_disable_intercept_for_msr(
 +					msr_bitmap_l1, msr_bitmap_l0,
 +					MSR_IA32_SPEC_CTRL,
 +					MSR_TYPE_R | MSR_TYPE_W);
 +
 +	if (pred_cmd)
 +		nested_vmx_disable_intercept_for_msr(
 +					msr_bitmap_l1, msr_bitmap_l0,
 +					MSR_IA32_PRED_CMD,
 +					MSR_TYPE_W);
 +
  	kunmap(page);
  	kvm_release_page_clean(page);
  

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/svm.c

between commit:

  15d45071523d ("KVM/x86: Add IBPB support")

from Linus' tree and commit:

  70cd94e60c73 ("KVM: SVM: VMRUN should use associated ASID when SEV is enabled")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/svm.c
index 4e3c79530526,1bf20e9160bd..000000000000
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@@ -533,7 -573,9 +577,10 @@@ struct svm_cpu_data 
  	struct kvm_ldttss_desc *tss_desc;
  
  	struct page *save_area;
 +	struct vmcb *current_vmcb;
+ 
+ 	/* index = sev_asid, value = vmcb pointer */
+ 	struct vmcb **sev_vmcbs;
  };
  
  static DEFINE_PER_CPU(struct svm_cpu_data *, svm_data);

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Radim Krčmář]

2018-02-02 11:20+1100, Stephen Rothwell:
> Hi Radim,
> 
> On Thu, 1 Feb 2018 16:22:44 +0100 Radim Krčmář <rkrcmar@redhat.com> wrote:
> >
> > I wasn't sure if the pti top branch is final, so I pulled hyper-v topic
> > branch that also also contains v4.15.  This and the SEV feature
> > conflicts should be gone now,
> 
> That merge would have been a good place to add the following merge
> resolution fix patch I have been carrying:

Yes, should have been there ... I've slapped the patch on top, thanks
for noticing.

> From: Eric Biggers <ebiggers@google.com>
> Subject: KVM: x86: don't forget vcpu_put() in kvm_arch_vcpu_ioctl_set_sregs()
> Date: Thu, 21 Dec 2017 01:30:30 +0100
> 
> Due to a bad merge resolution between commit f29810335965 ("KVM/x86:
> Check input paging mode when cs.l is set") and commit b4ef9d4e8cb8
> ("KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_sregs"),
> there is a case in kvm_arch_vcpu_ioctl_set_sregs() where vcpu_put() is
> not called after vcpu_get().  Fix it.
> 
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  arch/x86/kvm/x86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index ea3a98196753..f4e8b5089b28 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7624,7 +7624,7 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>  		goto out;
>  
>  	if (kvm_valid_sregs(vcpu, sregs))
> -		return -EINVAL;
> +		goto out;
>  
>  	apic_base_msr.data = sregs->apic_base;
>  	apic_base_msr.host_initiated = true;
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi Radim,

On Thu, 1 Feb 2018 16:22:44 +0100 Radim Krčmář <rkrcmar@redhat.com> wrote:
>
> I wasn't sure if the pti top branch is final, so I pulled hyper-v topic
> branch that also also contains v4.15.  This and the SEV feature
> conflicts should be gone now,

That merge would have been a good place to add the following merge
resolution fix patch I have been carrying:

From: Eric Biggers <ebiggers@google.com>
Subject: KVM: x86: don't forget vcpu_put() in kvm_arch_vcpu_ioctl_set_sregs()
Date: Thu, 21 Dec 2017 01:30:30 +0100

Due to a bad merge resolution between commit f29810335965 ("KVM/x86:
Check input paging mode when cs.l is set") and commit b4ef9d4e8cb8
("KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_sregs"),
there is a case in kvm_arch_vcpu_ioctl_set_sregs() where vcpu_put() is
not called after vcpu_get().  Fix it.

Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 arch/x86/kvm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ea3a98196753..f4e8b5089b28 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7624,7 +7624,7 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
 		goto out;
 
 	if (kvm_valid_sregs(vcpu, sregs))
-		return -EINVAL;
+		goto out;
 
 	apic_base_msr.data = sregs->apic_base;
 	apic_base_msr.host_initiated = true;

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

On 01/02/2018 10:22, Radim Krčmář wrote:
> 2018-02-01 09:21-0500, Paolo Bonzini:
>> On 01/02/2018 08:22, Stephen Rothwell wrote:
>>> Hi Christoffer,
>>>
>>> On Thu, 1 Feb 2018 11:47:07 +0100 Christoffer Dall <christoffer.dall@linaro.org> wrote:
>>>>
>>>> While the suggested fix is functional it does result in some code
>>>> duplication, and the better resolution is the following:
>>>
>>> OK, I will use that resolution form tomorrow on.
>>>
>>> Someone needs to remember to let Linus know when the pull request is
>>> sent.
>>
>> It should be fixed in the KVM tree before it reaches Linus (when we
>> merge a topic branch that is common between x86/pti & KVM).
> 
> I wasn't sure if the pti top branch is final, so I pulled hyper-v topic
> branch that also also contains v4.15.  This and the SEV feature
> conflicts should be gone now,

The pti topic branch is now updated with the v3 patches.  So if v3 is
good for you, it is final. :)

Paolo

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Radim Krčmář]

2018-02-01 09:21-0500, Paolo Bonzini:
> On 01/02/2018 08:22, Stephen Rothwell wrote:
> > Hi Christoffer,
> > 
> > On Thu, 1 Feb 2018 11:47:07 +0100 Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >>
> >> While the suggested fix is functional it does result in some code
> >> duplication, and the better resolution is the following:
> > 
> > OK, I will use that resolution form tomorrow on.
> > 
> > Someone needs to remember to let Linus know when the pull request is
> > sent.
> 
> It should be fixed in the KVM tree before it reaches Linus (when we
> merge a topic branch that is common between x86/pti & KVM).

I wasn't sure if the pti top branch is final, so I pulled hyper-v topic
branch that also also contains v4.15.  This and the SEV feature
conflicts should be gone now,

thanks.

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

On 01/02/2018 08:22, Stephen Rothwell wrote:
> Hi Christoffer,
> 
> On Thu, 1 Feb 2018 11:47:07 +0100 Christoffer Dall <christoffer.dall@linaro.org> wrote:
>>
>> While the suggested fix is functional it does result in some code
>> duplication, and the better resolution is the following:
> 
> OK, I will use that resolution form tomorrow on.
> 
> Someone needs to remember to let Linus know when the pull request is
> sent.

It should be fixed in the KVM tree before it reaches Linus (when we
merge a topic branch that is common between x86/pti & KVM).

Thanks,

Paolo

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Christoffer Dall]

On Fri, Feb 02, 2018 at 12:22:27AM +1100, Stephen Rothwell wrote:
> Hi Christoffer,
> 
> On Thu, 1 Feb 2018 11:47:07 +0100 Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >
> > While the suggested fix is functional it does result in some code
> > duplication, and the better resolution is the following:
> 
> OK, I will use that resolution form tomorrow on.
> 
> Someone needs to remember to let Linus know when the pull request is
> sent.
> 
I've sent a separate notice to Paolo and Radim, so I'm sure they'll take
care of it.

Thanks,
-Christoffer

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi Christoffer,

On Thu, 1 Feb 2018 11:47:07 +0100 Christoffer Dall <christoffer.dall@linaro.org> wrote:
>
> While the suggested fix is functional it does result in some code
> duplication, and the better resolution is the following:

OK, I will use that resolution form tomorrow on.

Someone needs to remember to let Linus know when the pull request is
sent.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Christoffer Dall]

Hi,

On Thu, Feb 01, 2018 at 12:55:12PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   virt/kvm/arm/arch_timer.c
> 
> between commit:
> 
>   36e5cfd410ad ("KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state")
> 
> from Linus' tree and commits:
> 
>   70450a9fbe06 ("KVM: arm/arm64: Don't cache the timer IRQ level")
>   13e59ece5b30 ("KVM: arm/arm64: Fix incorrect timer_is_pending logic")
> 
> from the kvm tree.
> 
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
While the suggested fix is functional it does result in some code
duplication, and the better resolution is the following:

diff --cc virt/kvm/arm/arch_timer.c
index cc29a8148328,fb6bd9b9845e..000000000000
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@@ -92,27 -92,18 +92,22 @@@ static irqreturn_t kvm_arch_timer_handl
  {
  	struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
  	struct arch_timer_context *vtimer;
- 	u32 cnt_ctl;
  
 -	if (!vcpu) {
 -		pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
 -		return IRQ_NONE;
 -	}
 +	/*
 +	 * We may see a timer interrupt after vcpu_put() has been called which
 +	 * sets the CPU's vcpu pointer to NULL, because even though the timer
 +	 * has been disabled in vtimer_save_state(), the hardware interrupt
 +	 * signal may not have been retired from the interrupt controller yet.
 +	 */
 +	if (!vcpu)
 +		return IRQ_HANDLED;
  
  	vtimer = vcpu_vtimer(vcpu);
- 	if (!vtimer->irq.level) {
- 		cnt_ctl = read_sysreg_el0(cntv_ctl);
- 		cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
- 			   ARCH_TIMER_CTRL_IT_MASK;
- 		if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
- 			kvm_timer_update_irq(vcpu, true, vtimer);
- 	}
+ 	if (kvm_timer_should_fire(vtimer))
+ 		kvm_timer_update_irq(vcpu, true, vtimer);
  
- 	if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
+ 	if (static_branch_unlikely(&userspace_irqchip_in_use) &&
+ 	    unlikely(!irqchip_in_kernel(vcpu->kvm)))
  		kvm_vtimer_update_mask_user(vcpu);
  
  	return IRQ_HANDLED;


Thanks,
-Christoffer

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  virt/kvm/arm/arch_timer.c

between commit:

  36e5cfd410ad ("KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state")

from Linus' tree and commits:

  70450a9fbe06 ("KVM: arm/arm64: Don't cache the timer IRQ level")
  13e59ece5b30 ("KVM: arm/arm64: Fix incorrect timer_is_pending logic")

from the kvm tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc virt/kvm/arm/arch_timer.c
index cc29a8148328,fb6bd9b9845e..000000000000
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@@ -92,27 -92,18 +92,26 @@@ static irqreturn_t kvm_arch_timer_handl
  {
  	struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
  	struct arch_timer_context *vtimer;
 +	u32 cnt_ctl;
  
 -	if (!vcpu) {
 -		pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
 -		return IRQ_NONE;
 -	}
 +	/*
 +	 * We may see a timer interrupt after vcpu_put() has been called which
 +	 * sets the CPU's vcpu pointer to NULL, because even though the timer
 +	 * has been disabled in vtimer_save_state(), the hardware interrupt
 +	 * signal may not have been retired from the interrupt controller yet.
 +	 */
 +	if (!vcpu)
 +		return IRQ_HANDLED;
  
  	vtimer = vcpu_vtimer(vcpu);
- 	if (!vtimer->irq.level) {
- 		cnt_ctl = read_sysreg_el0(cntv_ctl);
- 		cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
- 			   ARCH_TIMER_CTRL_IT_MASK;
- 		if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
- 			kvm_timer_update_irq(vcpu, true, vtimer);
- 	}
- 
- 	if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
 -	if (kvm_timer_should_fire(vtimer))
++	cnt_ctl = read_sysreg_el0(cntv_ctl);
++	cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
++		   ARCH_TIMER_CTRL_IT_MASK;
++	if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
+ 		kvm_timer_update_irq(vcpu, true, vtimer);
+ 
+ 	if (static_branch_unlikely(&userspace_irqchip_in_use) &&
+ 	    unlikely(!irqchip_in_kernel(vcpu->kvm)))
  		kvm_vtimer_update_mask_user(vcpu);
  
  	return IRQ_HANDLED;

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

On 29/01/2018 05:02, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 17 Jan 2018 13:53:26 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> On Wed, 17 Jan 2018, Stephen Rothwell wrote:
>>> On Wed, 17 Jan 2018 13:23:17 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:  
>>>> No. Keep it and lets next time coordinate the relevant bits and pieces
>>>> better. I reserve that bit 20 and let Linus sort out the trivial conflict
>>>> when merging the stuff.  
>>>
>>> I just picked that bit 20 when resolving the conflict.  The original patch used
>>> bit 11, so the resolution could use any other sensible bit.  
>>
>> 20 is fine :)
> 
> So maybe this (X86_FEATURE_SEV) should be fixed up to use "( 7*32+20)" in
> the kvm tree?  (Just a followup patch changing the value/position in the
> file would be fine).

Yes, we'll fix this and the other conflicts with Linus's tree before
sending out the pull request.

Paolo

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

On Wed, 17 Jan 2018 13:53:26 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> > On Wed, 17 Jan 2018 13:23:17 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:  
> > > No. Keep it and lets next time coordinate the relevant bits and pieces
> > > better. I reserve that bit 20 and let Linus sort out the trivial conflict
> > > when merging the stuff.  
> > 
> > I just picked that bit 20 when resolving the conflict.  The original patch used
> > bit 11, so the resolution could use any other sensible bit.  
> 
> 20 is fine :)

So maybe this (X86_FEATURE_SEV) should be fixed up to use "( 7*32+20)" in
the kvm tree?  (Just a followup patch changing the value/position in the
file would be fine).
-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  Documentation/virtual/kvm/api.txt

between commit:

  3214d01f139b ("KVM: PPC: Book3S: Provide information about hardware/firmware CVE workarounds")

from Linus' tree and commit:

  5acc5c063196 ("KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/virtual/kvm/api.txt
index fc3ae951bc07,e5f1743e0b3e..000000000000
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -3403,52 -3403,56 +3403,102 @@@ invalid, if invalid pages are written t
  or if no page table is present for the addresses (e.g. when using
  hugepages).
  
 +4.108 KVM_PPC_GET_CPU_CHAR
 +
 +Capability: KVM_CAP_PPC_GET_CPU_CHAR
 +Architectures: powerpc
 +Type: vm ioctl
 +Parameters: struct kvm_ppc_cpu_char (out)
 +Returns: 0 on successful completion
 +	 -EFAULT if struct kvm_ppc_cpu_char cannot be written
 +
 +This ioctl gives userspace information about certain characteristics
 +of the CPU relating to speculative execution of instructions and
 +possible information leakage resulting from speculative execution (see
 +CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754).  The information is
 +returned in struct kvm_ppc_cpu_char, which looks like this:
 +
 +struct kvm_ppc_cpu_char {
 +	__u64	character;		/* characteristics of the CPU */
 +	__u64	behaviour;		/* recommended software behaviour */
 +	__u64	character_mask;		/* valid bits in character */
 +	__u64	behaviour_mask;		/* valid bits in behaviour */
 +};
 +
 +For extensibility, the character_mask and behaviour_mask fields
 +indicate which bits of character and behaviour have been filled in by
 +the kernel.  If the set of defined bits is extended in future then
 +userspace will be able to tell whether it is running on a kernel that
 +knows about the new bits.
 +
 +The character field describes attributes of the CPU which can help
 +with preventing inadvertent information disclosure - specifically,
 +whether there is an instruction to flash-invalidate the L1 data cache
 +(ori 30,30,0 or mtspr SPRN_TRIG2,rN), whether the L1 data cache is set
 +to a mode where entries can only be used by the thread that created
 +them, whether the bcctr[l] instruction prevents speculation, and
 +whether a speculation barrier instruction (ori 31,31,0) is provided.
 +
 +The behaviour field describes actions that software should take to
 +prevent inadvertent information disclosure, and thus describes which
 +vulnerabilities the hardware is subject to; specifically whether the
 +L1 data cache should be flushed when returning to user mode from the
 +kernel, and whether a speculation barrier should be placed between an
 +array bounds check and the array access.
 +
 +These fields use the same bit definitions as the new
 +H_GET_CPU_CHARACTERISTICS hypercall.
 +
+ 4.109 KVM_MEMORY_ENCRYPT_OP
+ 
+ Capability: basic
+ Architectures: x86
+ Type: system
+ Parameters: an opaque platform specific structure (in/out)
+ Returns: 0 on success; -1 on error
+ 
+ If the platform supports creating encrypted VMs then this ioctl can be used
+ for issuing platform-specific memory encryption commands to manage those
+ encrypted VMs.
+ 
+ Currently, this ioctl is used for issuing Secure Encrypted Virtualization
+ (SEV) commands on AMD Processors. The SEV commands are defined in
+ Documentation/virtual/kvm/amd-memory-encryption.txt.
+ 
+ 4.110 KVM_MEMORY_ENCRYPT_REG_REGION
+ 
+ Capability: basic
+ Architectures: x86
+ Type: system
+ Parameters: struct kvm_enc_region (in)
+ Returns: 0 on success; -1 on error
+ 
+ This ioctl can be used to register a guest memory region which may
+ contain encrypted data (e.g. guest RAM, SMRAM etc).
+ 
+ It is used in the SEV-enabled guest. When encryption is enabled, a guest
+ memory region may contain encrypted data. The SEV memory encryption
+ engine uses a tweak such that two identical plaintext pages, each at
+ different locations will have differing ciphertexts. So swapping or
+ moving ciphertext of those pages will not result in plaintext being
+ swapped. So relocating (or migrating) physical backing pages for the SEV
+ guest will require some additional steps.
+ 
+ Note: The current SEV key management spec does not provide commands to
+ swap or migrate (move) ciphertext pages. Hence, for now we pin the guest
+ memory region registered with the ioctl.
+ 
+ 4.111 KVM_MEMORY_ENCRYPT_UNREG_REGION
+ 
+ Capability: basic
+ Architectures: x86
+ Type: system
+ Parameters: struct kvm_enc_region (in)
+ Returns: 0 on success; -1 on error
+ 
+ This ioctl can be used to unregister the guest memory region registered
+ with KVM_MEMORY_ENCRYPT_REG_REGION ioctl above.
+ 
  5. The kvm_run structure
  ------------------------
  

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Thomas Gleixner]

On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> On Wed, 17 Jan 2018 13:23:17 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
> > No. Keep it and lets next time coordinate the relevant bits and pieces
> > better. I reserve that bit 20 and let Linus sort out the trivial conflict
> > when merging the stuff.
> 
> I just picked that bit 20 when resolving the conflict.  The original patch used
> bit 11, so the resolution could use any other sensible bit.

20 is fine :)

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi Thomas,

On Wed, 17 Jan 2018 13:23:17 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> > On 17/01/2018 12:45, Thomas Gleixner wrote:  
> > > On Wed, 17 Jan 2018, Stephen Rothwell wrote:  
> > >> [This is the same conflict I reported the day before yesterday, but one
> > >> of the commits has moved and another that contributed has been dropped.]
> > >> diff --cc arch/x86/include/asm/cpufeatures.h
> > >> index aa09559b2c0b,19f35be95f16..000000000000
> > >> --- a/arch/x86/include/asm/cpufeatures.h
> > >> +++ b/arch/x86/include/asm/cpufeatures.h
> > >> @@@ -211,7 -209,6 +211,8 @@@
> > >>   #define X86_FEATURE_AVX512_4FMAPS	( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */
> > >>   
> > >>   #define X86_FEATURE_MBA			( 7*32+18) /* Memory Bandwidth Allocation */
> > >>  +#define X86_FEATURE_RSB_CTXSW		( 7*32+19) /* Fill RSB on context switches */
> > >> ++#define X86_FEATURE_SEV			( 7*32+20) /* AMD Secure Encrypted Virtualization */  
> > > Groan.....
> > >   
> > 
> > Brijesh,
> > 
> > please send out again the (host-side) SEV series so that they are merged
> > through the TIP tree instead of kvm.git.
> > 
> > Even though Boris did review it, there's just too much stuff in there
> > outside arch/x86/kvm.  
> 
> No. Keep it and lets next time coordinate the relevant bits and pieces
> better. I reserve that bit 20 and let Linus sort out the trivial conflict
> when merging the stuff.

I just picked that bit 20 when resolving the conflict.  The original patch used
bit 11, so the resolution could use any other sensible bit.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Thomas Gleixner]

On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> On 17/01/2018 13:23, Thomas Gleixner wrote:
> > No. Keep it and lets next time coordinate the relevant bits and pieces
> > better. I reserve that bit 20 and let Linus sort out the trivial conflict
> > when merging the stuff.
> 
> Thank you.  In the future we'll make sure to contact you before merging
> this kind of change.

I didnt pay much attention as I was burried in the melted spectrum ....

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

On 17/01/2018 13:23, Thomas Gleixner wrote:
> On Wed, 17 Jan 2018, Paolo Bonzini wrote:
>> On 17/01/2018 12:45, Thomas Gleixner wrote:
>>> On Wed, 17 Jan 2018, Stephen Rothwell wrote:
>>>> [This is the same conflict I reported the day before yesterday, but one
>>>> of the commits has moved and another that contributed has been dropped.]
>>>> diff --cc arch/x86/include/asm/cpufeatures.h
>>>> index aa09559b2c0b,19f35be95f16..000000000000
>>>> --- a/arch/x86/include/asm/cpufeatures.h
>>>> +++ b/arch/x86/include/asm/cpufeatures.h
>>>> @@@ -211,7 -209,6 +211,8 @@@
>>>>   #define X86_FEATURE_AVX512_4FMAPS	( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */
>>>>   
>>>>   #define X86_FEATURE_MBA			( 7*32+18) /* Memory Bandwidth Allocation */
>>>>  +#define X86_FEATURE_RSB_CTXSW		( 7*32+19) /* Fill RSB on context switches */
>>>> ++#define X86_FEATURE_SEV			( 7*32+20) /* AMD Secure Encrypted Virtualization */
>>> Groan.....
>>>
>>
>> Brijesh,
>>
>> please send out again the (host-side) SEV series so that they are merged
>> through the TIP tree instead of kvm.git.
>>
>> Even though Boris did review it, there's just too much stuff in there
>> outside arch/x86/kvm.
> 
> No. Keep it and lets next time coordinate the relevant bits and pieces
> better. I reserve that bit 20 and let Linus sort out the trivial conflict
> when merging the stuff.

Thank you.  In the future we'll make sure to contact you before merging
this kind of change.

Thanks,

Paolo

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Thomas Gleixner]

On Wed, 17 Jan 2018, Paolo Bonzini wrote:
> On 17/01/2018 12:45, Thomas Gleixner wrote:
> > On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> >> [This is the same conflict I reported the day before yesterday, but one
> >> of the commits has moved and another that contributed has been dropped.]
> >> diff --cc arch/x86/include/asm/cpufeatures.h
> >> index aa09559b2c0b,19f35be95f16..000000000000
> >> --- a/arch/x86/include/asm/cpufeatures.h
> >> +++ b/arch/x86/include/asm/cpufeatures.h
> >> @@@ -211,7 -209,6 +211,8 @@@
> >>   #define X86_FEATURE_AVX512_4FMAPS	( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */
> >>   
> >>   #define X86_FEATURE_MBA			( 7*32+18) /* Memory Bandwidth Allocation */
> >>  +#define X86_FEATURE_RSB_CTXSW		( 7*32+19) /* Fill RSB on context switches */
> >> ++#define X86_FEATURE_SEV			( 7*32+20) /* AMD Secure Encrypted Virtualization */
> > Groan.....
> > 
> 
> Brijesh,
> 
> please send out again the (host-side) SEV series so that they are merged
> through the TIP tree instead of kvm.git.
> 
> Even though Boris did review it, there's just too much stuff in there
> outside arch/x86/kvm.

No. Keep it and lets next time coordinate the relevant bits and pieces
better. I reserve that bit 20 and let Linus sort out the trivial conflict
when merging the stuff.

Thanks,

	tglx

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

On 17/01/2018 12:45, Thomas Gleixner wrote:
> On Wed, 17 Jan 2018, Stephen Rothwell wrote:
>> [This is the same conflict I reported the day before yesterday, but one
>> of the commits has moved and another that contributed has been dropped.]
>> diff --cc arch/x86/include/asm/cpufeatures.h
>> index aa09559b2c0b,19f35be95f16..000000000000
>> --- a/arch/x86/include/asm/cpufeatures.h
>> +++ b/arch/x86/include/asm/cpufeatures.h
>> @@@ -211,7 -209,6 +211,8 @@@
>>   #define X86_FEATURE_AVX512_4FMAPS	( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */
>>   
>>   #define X86_FEATURE_MBA			( 7*32+18) /* Memory Bandwidth Allocation */
>>  +#define X86_FEATURE_RSB_CTXSW		( 7*32+19) /* Fill RSB on context switches */
>> ++#define X86_FEATURE_SEV			( 7*32+20) /* AMD Secure Encrypted Virtualization */
> Groan.....
> 

Brijesh,

please send out again the (host-side) SEV series so that they are merged
through the TIP tree instead of kvm.git.

Even though Boris did review it, there's just too much stuff in there
outside arch/x86/kvm.

Thanks,

Paolo

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Thomas Gleixner]

On Wed, 17 Jan 2018, Stephen Rothwell wrote:
> [This is the same conflict I reported the day before yesterday, but one
> of the commits has moved and another that contributed has been dropped.]
> diff --cc arch/x86/include/asm/cpufeatures.h
> index aa09559b2c0b,19f35be95f16..000000000000
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@@ -211,7 -209,6 +211,8 @@@
>   #define X86_FEATURE_AVX512_4FMAPS	( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */
>   
>   #define X86_FEATURE_MBA			( 7*32+18) /* Memory Bandwidth Allocation */
>  +#define X86_FEATURE_RSB_CTXSW		( 7*32+19) /* Fill RSB on context switches */
> ++#define X86_FEATURE_SEV			( 7*32+20) /* AMD Secure Encrypted Virtualization */

Groan.....

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

[This is the same conflict I reported the day before yesterday, but one
of the commits has moved and another that contributed has been dropped.]

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/include/asm/cpufeatures.h

between commits:

  a89f040fa34e ("x86/cpufeatures: Add X86_BUG_CPU_INSECURE")
  76b043848fd2 ("x86/retpoline: Add initial retpoline support")

from Linus' tree, commit:

  18c71ce9c882 ("x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/cpufeatures.h
index aa09559b2c0b,19f35be95f16..000000000000
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@@ -211,7 -209,6 +211,8 @@@
  #define X86_FEATURE_AVX512_4FMAPS	( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */
  
  #define X86_FEATURE_MBA			( 7*32+18) /* Memory Bandwidth Allocation */
 +#define X86_FEATURE_RSB_CTXSW		( 7*32+19) /* Fill RSB on context switches */
++#define X86_FEATURE_SEV			( 7*32+20) /* AMD Secure Encrypted Virtualization */
  
  /* Virtualization flags: Linux defined, word 8 */
  #define X86_FEATURE_TPR_SHADOW		( 8*32+ 0) /* Intel TPR Shadow */

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

On Fri, 25 Aug 2017 14:34:16 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/include/asm/cpufeatures.h
> 
> between commit:
> 
>   5442c2699552 ("x86/cpufeature, kvm/svm: Rename (shorten) the new "virtualized VMSAVE/VMLOAD" CPUID flag")
> 
> from Linus' tree and commit:
> 
>   d837312dfd5b ("KVM: SVM: Add Virtual GIF feature definition")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/include/asm/cpufeatures.h
> index 42bbbf0f173d,0e25e7a8ab03..000000000000
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@@ -287,7 -286,8 +287,8 @@@
>   #define X86_FEATURE_PAUSEFILTER (15*32+10) /* filtered pause intercept */
>   #define X86_FEATURE_PFTHRESHOLD (15*32+12) /* pause filter threshold */
>   #define X86_FEATURE_AVIC	(15*32+13) /* Virtual Interrupt Controller */
>  -#define X86_FEATURE_VIRTUAL_VMLOAD_VMSAVE (15*32+15) /* Virtual VMLOAD VMSAVE */
>  +#define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* Virtual VMSAVE VMLOAD */
> + #define X86_FEATURE_VGIF	(15*32+16) /* Virtual GIF */
>   
>   /* Intel-defined CPU features, CPUID level 0x00000007:0 (ecx), word 16 */
>   #define X86_FEATURE_AVX512VBMI  (16*32+ 1) /* AVX512 Vector Bit Manipulation instructions*/

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/include/asm/cpufeatures.h

between commit:

  5442c2699552 ("x86/cpufeature, kvm/svm: Rename (shorten) the new "virtualized VMSAVE/VMLOAD" CPUID flag")

from Linus' tree and commit:

  d837312dfd5b ("KVM: SVM: Add Virtual GIF feature definition")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/cpufeatures.h
index 42bbbf0f173d,0e25e7a8ab03..000000000000
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@@ -287,7 -286,8 +287,8 @@@
  #define X86_FEATURE_PAUSEFILTER (15*32+10) /* filtered pause intercept */
  #define X86_FEATURE_PFTHRESHOLD (15*32+12) /* pause filter threshold */
  #define X86_FEATURE_AVIC	(15*32+13) /* Virtual Interrupt Controller */
 -#define X86_FEATURE_VIRTUAL_VMLOAD_VMSAVE (15*32+15) /* Virtual VMLOAD VMSAVE */
 +#define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* Virtual VMSAVE VMLOAD */
+ #define X86_FEATURE_VGIF	(15*32+16) /* Virtual GIF */
  
  /* Intel-defined CPU features, CPUID level 0x00000007:0 (ecx), word 16 */
  #define X86_FEATURE_AVX512VBMI  (16*32+ 1) /* AVX512 Vector Bit Manipulation instructions*/

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/vmx.c

between commit:

  4e59516a12a6 ("kvm: vmx: ensure VMCS is current while enabling PML")

from Linus' tree and commit:

  37e4c997dadf ("KVM: VMX: validate individual bits of guest MSR_IA32_FEATURE_CONTROL")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index df4a3b818048,b61cdadf8623..000000000000
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -8954,6 -9086,20 +9105,8 @@@ static struct kvm_vcpu *vmx_create_vcpu
  	vmx->nested.current_vmptr = -1ull;
  	vmx->nested.current_vmcs12 = NULL;
  
 -	/*
 -	 * If PML is turned on, failure on enabling PML just results in failure
 -	 * of creating the vcpu, therefore we can simplify PML logic (by
 -	 * avoiding dealing with cases, such as enabling PML partially on vcpus
 -	 * for the guest, etc.
 -	 */
 -	if (enable_pml) {
 -		err = vmx_create_pml_buffer(vmx);
 -		if (err)
 -			goto free_vmcs;
 -	}
 -
+ 	vmx->msr_ia32_feature_control_valid_bits = FEATURE_CONTROL_LOCKED;
+ 
  	return &vmx->vcpu;
  
  free_vmcs:
@@@ -10913,7 -11149,17 +11161,17 @@@ out
  	return ret;
  }
  
+ static void vmx_setup_mce(struct kvm_vcpu *vcpu)
+ {
+ 	if (vcpu->arch.mcg_cap & MCG_LMCE_P)
+ 		to_vmx(vcpu)->msr_ia32_feature_control_valid_bits |=
+ 			FEATURE_CONTROL_LMCE;
+ 	else
+ 		to_vmx(vcpu)->msr_ia32_feature_control_valid_bits &=
+ 			~FEATURE_CONTROL_LMCE;
+ }
+ 
 -static struct kvm_x86_ops vmx_x86_ops = {
 +static struct kvm_x86_ops vmx_x86_ops __ro_after_init = {
  	.cpu_has_kvm_support = cpu_has_kvm_support,
  	.disabled_by_bios = vmx_disabled_by_bios,
  	.hardware_setup = hardware_setup,

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Paolo Bonzini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 25/05/2015 09:25, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in 
> arch/x86/kvm/x86.c between commit c447e76b4cab ("kvm/fpu: Enable
> eager restore kvm FPU for MPX") from the  tree and commit
> 653f52c316a4 ("kvm,x86: load guest FPU context more eagerly") from
> the kvm tree.
> 
> I fixed it up (I used the version from the kvm tree) and can carry
> the fix as necessary (no action is required).

A true conflict resolution is needed, but I'll push it to the kvm tree
in the next few days.

Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVYy2iAAoJEL/70l94x66DibAH/04gli1LtFZbqOMHgxId+8qc
HB1aqK/LBin4wdFmlBFUDT9AH1Q08SZ0sghmnOiQb17WZs9YRGBMKUJq+OPt/lky
EgCSzv9iBAkuOLKC1tPmjDhKBok1SNWipqIUj1UtCKCtVBdWd7yG3C99KQQPT46V
a66Jhk1KG7CryrqBfRpDnKSXbQTWiBFH4r6z2XAKboFiTMIp8EsWErMzHv7km5Zd
Nw8Ia0AyAsVF4C85J00dQDeuQdwyfLyQEb+s7Zf5qFLIYO/Zd5HXezX8y8rDuSu9
UIDtkKcebU1ddrXa/ocja3df52IMOsRLW1lg3shFO0MLWAqRtcx3WnqWC6J8Dx8=
=AHYH
-----END PGP SIGNATURE-----

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kvm/x86.c between commit c447e76b4cab ("kvm/fpu: Enable eager
restore kvm FPU for MPX") from the  tree and commit 653f52c316a4
("kvm,x86: load guest FPU context more eagerly") from the kvm tree.

I fixed it up (I used the version from the kvm tree) and can carry the
fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 7916 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/arm/kvm/mmu.c between commit 0d3e4d4fade6 ("arm/arm64: KVM: Use
kernel mapping to perform invalidation on page fault"") from Linus'
tree and commit 3b0f1d01e501 ("KVM: Rename
kvm_arch_mmu_write_protect_pt_masked to be more generic for log dirty")
from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/kvm/mmu.c
index 136662547ca6,6034697ede3f..000000000000
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@@ -58,26 -78,25 +78,45 @@@ static void kvm_tlb_flush_vmid_ipa(stru
  		kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
  }
  
 +/*
 + * D-Cache management functions. They take the page table entries by
 + * value, as they are flushing the cache using the kernel mapping (or
 + * kmap on 32bit).
 + */
 +static void kvm_flush_dcache_pte(pte_t pte)
 +{
 +	__kvm_flush_dcache_pte(pte);
 +}
 +
 +static void kvm_flush_dcache_pmd(pmd_t pmd)
 +{
 +	__kvm_flush_dcache_pmd(pmd);
 +}
 +
 +static void kvm_flush_dcache_pud(pud_t pud)
 +{
 +	__kvm_flush_dcache_pud(pud);
 +}
 +
+ /**
+  * stage2_dissolve_pmd() - clear and flush huge PMD entry
+  * @kvm:	pointer to kvm structure.
+  * @addr:	IPA
+  * @pmd:	pmd pointer for IPA
+  *
+  * Function clears a PMD entry, flushes addr 1st and 2nd stage TLBs. Marks all
+  * pages in the range dirty.
+  */
+ static void stage2_dissolve_pmd(struct kvm *kvm, phys_addr_t addr, pmd_t *pmd)
+ {
+ 	if (!kvm_pmd_huge(*pmd))
+ 		return;
+ 
+ 	pmd_clear(pmd);
+ 	kvm_tlb_flush_vmid_ipa(kvm, addr);
+ 	put_page(virt_to_page(pmd));
+ }
+ 
  static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
  				  int min, int max)
  {
@@@ -957,12 -957,165 +1009,171 @@@ static bool kvm_is_device_pfn(unsigned 
  	return !pfn_valid(pfn);
  }
  
 +static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, pfn_t pfn,
 +				      unsigned long size, bool uncached)
 +{
 +	__coherent_cache_guest_page(vcpu, pfn, size, uncached);
 +}
 +
+ /**
+  * stage2_wp_ptes - write protect PMD range
+  * @pmd:	pointer to pmd entry
+  * @addr:	range start address
+  * @end:	range end address
+  */
+ static void stage2_wp_ptes(pmd_t *pmd, phys_addr_t addr, phys_addr_t end)
+ {
+ 	pte_t *pte;
+ 
+ 	pte = pte_offset_kernel(pmd, addr);
+ 	do {
+ 		if (!pte_none(*pte)) {
+ 			if (!kvm_s2pte_readonly(pte))
+ 				kvm_set_s2pte_readonly(pte);
+ 		}
+ 	} while (pte++, addr += PAGE_SIZE, addr != end);
+ }
+ 
+ /**
+  * stage2_wp_pmds - write protect PUD range
+  * @pud:	pointer to pud entry
+  * @addr:	range start address
+  * @end:	range end address
+  */
+ static void stage2_wp_pmds(pud_t *pud, phys_addr_t addr, phys_addr_t end)
+ {
+ 	pmd_t *pmd;
+ 	phys_addr_t next;
+ 
+ 	pmd = pmd_offset(pud, addr);
+ 
+ 	do {
+ 		next = kvm_pmd_addr_end(addr, end);
+ 		if (!pmd_none(*pmd)) {
+ 			if (kvm_pmd_huge(*pmd)) {
+ 				if (!kvm_s2pmd_readonly(pmd))
+ 					kvm_set_s2pmd_readonly(pmd);
+ 			} else {
+ 				stage2_wp_ptes(pmd, addr, next);
+ 			}
+ 		}
+ 	} while (pmd++, addr = next, addr != end);
+ }
+ 
+ /**
+   * stage2_wp_puds - write protect PGD range
+   * @pgd:	pointer to pgd entry
+   * @addr:	range start address
+   * @end:	range end address
+   *
+   * Process PUD entries, for a huge PUD we cause a panic.
+   */
+ static void  stage2_wp_puds(pgd_t *pgd, phys_addr_t addr, phys_addr_t end)
+ {
+ 	pud_t *pud;
+ 	phys_addr_t next;
+ 
+ 	pud = pud_offset(pgd, addr);
+ 	do {
+ 		next = kvm_pud_addr_end(addr, end);
+ 		if (!pud_none(*pud)) {
+ 			/* TODO:PUD not supported, revisit later if supported */
+ 			BUG_ON(kvm_pud_huge(*pud));
+ 			stage2_wp_pmds(pud, addr, next);
+ 		}
+ 	} while (pud++, addr = next, addr != end);
+ }
+ 
+ /**
+  * stage2_wp_range() - write protect stage2 memory region range
+  * @kvm:	The KVM pointer
+  * @addr:	Start address of range
+  * @end:	End address of range
+  */
+ static void stage2_wp_range(struct kvm *kvm, phys_addr_t addr, phys_addr_t end)
+ {
+ 	pgd_t *pgd;
+ 	phys_addr_t next;
+ 
+ 	pgd = kvm->arch.pgd + pgd_index(addr);
+ 	do {
+ 		/*
+ 		 * Release kvm_mmu_lock periodically if the memory region is
+ 		 * large. Otherwise, we may see kernel panics with
+ 		 * CONFIG_DETECT_HUNG_TASK, CONFIG_LOCKUP_DETECTOR,
+ 		 * CONFIG_LOCKDEP. Additionally, holding the lock too long
+ 		 * will also starve other vCPUs.
+ 		 */
+ 		if (need_resched() || spin_needbreak(&kvm->mmu_lock))
+ 			cond_resched_lock(&kvm->mmu_lock);
+ 
+ 		next = kvm_pgd_addr_end(addr, end);
+ 		if (pgd_present(*pgd))
+ 			stage2_wp_puds(pgd, addr, next);
+ 	} while (pgd++, addr = next, addr != end);
+ }
+ 
+ /**
+  * kvm_mmu_wp_memory_region() - write protect stage 2 entries for memory slot
+  * @kvm:	The KVM pointer
+  * @slot:	The memory slot to write protect
+  *
+  * Called to start logging dirty pages after memory region
+  * KVM_MEM_LOG_DIRTY_PAGES operation is called. After this function returns
+  * all present PMD and PTEs are write protected in the memory region.
+  * Afterwards read of dirty page log can be called.
+  *
+  * Acquires kvm_mmu_lock. Called with kvm->slots_lock mutex acquired,
+  * serializing operations for VM memory regions.
+  */
+ void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot)
+ {
+ 	struct kvm_memory_slot *memslot = id_to_memslot(kvm->memslots, slot);
+ 	phys_addr_t start = memslot->base_gfn << PAGE_SHIFT;
+ 	phys_addr_t end = (memslot->base_gfn + memslot->npages) << PAGE_SHIFT;
+ 
+ 	spin_lock(&kvm->mmu_lock);
+ 	stage2_wp_range(kvm, start, end);
+ 	spin_unlock(&kvm->mmu_lock);
+ 	kvm_flush_remote_tlbs(kvm);
+ }
+ 
+ /**
+  * kvm_mmu_write_protect_pt_masked() - write protect dirty pages
+  * @kvm:	The KVM pointer
+  * @slot:	The memory slot associated with mask
+  * @gfn_offset:	The gfn offset in memory slot
+  * @mask:	The mask of dirty pages at offset 'gfn_offset' in this memory
+  *		slot to be write protected
+  *
+  * Walks bits set in mask write protects the associated pte's. Caller must
+  * acquire kvm_mmu_lock.
+  */
+ static void kvm_mmu_write_protect_pt_masked(struct kvm *kvm,
+ 		struct kvm_memory_slot *slot,
+ 		gfn_t gfn_offset, unsigned long mask)
+ {
+ 	phys_addr_t base_gfn = slot->base_gfn + gfn_offset;
+ 	phys_addr_t start = (base_gfn +  __ffs(mask)) << PAGE_SHIFT;
+ 	phys_addr_t end = (base_gfn + __fls(mask) + 1) << PAGE_SHIFT;
+ 
+ 	stage2_wp_range(kvm, start, end);
+ }
+ 
+ /*
+  * kvm_arch_mmu_enable_log_dirty_pt_masked - enable dirty logging for selected
+  * dirty pages.
+  *
+  * It calls kvm_mmu_write_protect_pt_masked to write protect selected pages to
+  * enable dirty logging for them.
+  */
+ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
+ 		struct kvm_memory_slot *slot,
+ 		gfn_t gfn_offset, unsigned long mask)
+ {
+ 	kvm_mmu_write_protect_pt_masked(kvm, slot, gfn_offset, mask);
+ }
+ 
  static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
  			  struct kvm_memory_slot *memslot, unsigned long hva,
  			  unsigned long fault_status)
@@@ -1059,13 -1234,13 +1291,12 @@@
  		if (writable) {
  			kvm_set_s2pte_writable(&new_pte);
  			kvm_set_pfn_dirty(pfn);
+ 			mark_page_dirty(kvm, gfn);
  		}
 -		coherent_cache_guest_page(vcpu, hva, PAGE_SIZE,
 -					  fault_ipa_uncached);
 +		coherent_cache_guest_page(vcpu, pfn, PAGE_SIZE, fault_ipa_uncached);
- 		ret = stage2_set_pte(kvm, memcache, fault_ipa, &new_pte,
- 			pgprot_val(mem_type) == pgprot_val(PAGE_S2_DEVICE));
+ 		ret = stage2_set_pte(kvm, memcache, fault_ipa, &new_pte, flags);
  	}
  
- 
  out_unlock:
  	spin_unlock(&kvm->mmu_lock);
  	kvm_release_pfn_clean(pfn);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/arm64/kvm/sys_regs.c between commit 3c1e71650833 ("arm/arm64: KVM:
Use set/way op trapping to track the state of the caches") from Linus'
tree and commit 6d52f35af10c ("arm64: KVM: add SGI generation register
emulation") from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/kvm/sys_regs.c
index b96afdf6cee4,7ad7af51856f..000000000000
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@@ -605,7 -693,9 +638,9 @@@ static const struct sys_reg_desc cp14_6
   * register).
   */
  static const struct sys_reg_desc cp15_regs[] = {
+ 	{ Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
+ 
 -	{ Op1( 0), CRn( 1), CRm( 0), Op2( 0), access_sctlr, NULL, c1_SCTLR },
 +	{ Op1( 0), CRn( 1), CRm( 0), Op2( 0), access_vm_reg, NULL, c1_SCTLR },
  	{ Op1( 0), CRn( 2), CRm( 0), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
  	{ Op1( 0), CRn( 2), CRm( 0), Op2( 1), access_vm_reg, NULL, c2_TTBR1 },
  	{ Op1( 0), CRn( 2), CRm( 0), Op2( 2), access_vm_reg, NULL, c2_TTBCR },

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 7750 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/arm/kvm/mmu.c between commits 363ef89f8e9b ("arm/arm64: KVM:
Invalidate data cache on unmap") and 0d3e4d4fade6 ("arm/arm64: KVM: Use
kernel mapping to perform invalidation on page fault") from Linus' tree
and commits c64735554c0a ("KVM: arm: Add initial dirty page locking
support"), 53c810c364d7 ("KVM: arm: dirty logging write protect
support") and 15a49a44fc36 ("KVM: arm: page logging 2nd stage fault
handling") from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

P.S. commits c64735554c0a, 53c810c364d7 and 15a49a44fc36 have no
signed-off-by from their committer (Christoffer Dall).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/kvm/mmu.c
index 136662547ca6,74aeabaa3c4d..000000000000
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@@ -58,26 -78,25 +78,45 @@@ static void kvm_tlb_flush_vmid_ipa(stru
  		kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
  }
  
 +/*
 + * D-Cache management functions. They take the page table entries by
 + * value, as they are flushing the cache using the kernel mapping (or
 + * kmap on 32bit).
 + */
 +static void kvm_flush_dcache_pte(pte_t pte)
 +{
 +	__kvm_flush_dcache_pte(pte);
 +}
 +
 +static void kvm_flush_dcache_pmd(pmd_t pmd)
 +{
 +	__kvm_flush_dcache_pmd(pmd);
 +}
 +
 +static void kvm_flush_dcache_pud(pud_t pud)
 +{
 +	__kvm_flush_dcache_pud(pud);
 +}
 +
+ /**
+  * stage2_dissolve_pmd() - clear and flush huge PMD entry
+  * @kvm:	pointer to kvm structure.
+  * @addr:	IPA
+  * @pmd:	pmd pointer for IPA
+  *
+  * Function clears a PMD entry, flushes addr 1st and 2nd stage TLBs. Marks all
+  * pages in the range dirty.
+  */
+ static void stage2_dissolve_pmd(struct kvm *kvm, phys_addr_t addr, pmd_t *pmd)
+ {
+ 	if (!kvm_pmd_huge(*pmd))
+ 		return;
+ 
+ 	pmd_clear(pmd);
+ 	kvm_tlb_flush_vmid_ipa(kvm, addr);
+ 	put_page(virt_to_page(pmd));
+ }
+ 
  static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
  				  int min, int max)
  {
@@@ -957,12 -957,151 +1009,157 @@@ static bool kvm_is_device_pfn(unsigned 
  	return !pfn_valid(pfn);
  }
  
 +static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, pfn_t pfn,
 +				      unsigned long size, bool uncached)
 +{
 +	__coherent_cache_guest_page(vcpu, pfn, size, uncached);
 +}
 +
+ /**
+  * stage2_wp_ptes - write protect PMD range
+  * @pmd:	pointer to pmd entry
+  * @addr:	range start address
+  * @end:	range end address
+  */
+ static void stage2_wp_ptes(pmd_t *pmd, phys_addr_t addr, phys_addr_t end)
+ {
+ 	pte_t *pte;
+ 
+ 	pte = pte_offset_kernel(pmd, addr);
+ 	do {
+ 		if (!pte_none(*pte)) {
+ 			if (!kvm_s2pte_readonly(pte))
+ 				kvm_set_s2pte_readonly(pte);
+ 		}
+ 	} while (pte++, addr += PAGE_SIZE, addr != end);
+ }
+ 
+ /**
+  * stage2_wp_pmds - write protect PUD range
+  * @pud:	pointer to pud entry
+  * @addr:	range start address
+  * @end:	range end address
+  */
+ static void stage2_wp_pmds(pud_t *pud, phys_addr_t addr, phys_addr_t end)
+ {
+ 	pmd_t *pmd;
+ 	phys_addr_t next;
+ 
+ 	pmd = pmd_offset(pud, addr);
+ 
+ 	do {
+ 		next = kvm_pmd_addr_end(addr, end);
+ 		if (!pmd_none(*pmd)) {
+ 			if (kvm_pmd_huge(*pmd)) {
+ 				if (!kvm_s2pmd_readonly(pmd))
+ 					kvm_set_s2pmd_readonly(pmd);
+ 			} else {
+ 				stage2_wp_ptes(pmd, addr, next);
+ 			}
+ 		}
+ 	} while (pmd++, addr = next, addr != end);
+ }
+ 
+ /**
+   * stage2_wp_puds - write protect PGD range
+   * @pgd:	pointer to pgd entry
+   * @addr:	range start address
+   * @end:	range end address
+   *
+   * Process PUD entries, for a huge PUD we cause a panic.
+   */
+ static void  stage2_wp_puds(pgd_t *pgd, phys_addr_t addr, phys_addr_t end)
+ {
+ 	pud_t *pud;
+ 	phys_addr_t next;
+ 
+ 	pud = pud_offset(pgd, addr);
+ 	do {
+ 		next = kvm_pud_addr_end(addr, end);
+ 		if (!pud_none(*pud)) {
+ 			/* TODO:PUD not supported, revisit later if supported */
+ 			BUG_ON(kvm_pud_huge(*pud));
+ 			stage2_wp_pmds(pud, addr, next);
+ 		}
+ 	} while (pud++, addr = next, addr != end);
+ }
+ 
+ /**
+  * stage2_wp_range() - write protect stage2 memory region range
+  * @kvm:	The KVM pointer
+  * @addr:	Start address of range
+  * @end:	End address of range
+  */
+ static void stage2_wp_range(struct kvm *kvm, phys_addr_t addr, phys_addr_t end)
+ {
+ 	pgd_t *pgd;
+ 	phys_addr_t next;
+ 
+ 	pgd = kvm->arch.pgd + pgd_index(addr);
+ 	do {
+ 		/*
+ 		 * Release kvm_mmu_lock periodically if the memory region is
+ 		 * large. Otherwise, we may see kernel panics with
+ 		 * CONFIG_DETECT_HUNG_TASK, CONFIG_LOCKUP_DETECTOR,
+ 		 * CONFIG_LOCKDEP. Additionally, holding the lock too long
+ 		 * will also starve other vCPUs.
+ 		 */
+ 		if (need_resched() || spin_needbreak(&kvm->mmu_lock))
+ 			cond_resched_lock(&kvm->mmu_lock);
+ 
+ 		next = kvm_pgd_addr_end(addr, end);
+ 		if (pgd_present(*pgd))
+ 			stage2_wp_puds(pgd, addr, next);
+ 	} while (pgd++, addr = next, addr != end);
+ }
+ 
+ /**
+  * kvm_mmu_wp_memory_region() - write protect stage 2 entries for memory slot
+  * @kvm:	The KVM pointer
+  * @slot:	The memory slot to write protect
+  *
+  * Called to start logging dirty pages after memory region
+  * KVM_MEM_LOG_DIRTY_PAGES operation is called. After this function returns
+  * all present PMD and PTEs are write protected in the memory region.
+  * Afterwards read of dirty page log can be called.
+  *
+  * Acquires kvm_mmu_lock. Called with kvm->slots_lock mutex acquired,
+  * serializing operations for VM memory regions.
+  */
+ void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot)
+ {
+ 	struct kvm_memory_slot *memslot = id_to_memslot(kvm->memslots, slot);
+ 	phys_addr_t start = memslot->base_gfn << PAGE_SHIFT;
+ 	phys_addr_t end = (memslot->base_gfn + memslot->npages) << PAGE_SHIFT;
+ 
+ 	spin_lock(&kvm->mmu_lock);
+ 	stage2_wp_range(kvm, start, end);
+ 	spin_unlock(&kvm->mmu_lock);
+ 	kvm_flush_remote_tlbs(kvm);
+ }
+ 
+ /**
+  * kvm_arch_mmu_write_protect_pt_masked() - write protect dirty pages
+  * @kvm:	The KVM pointer
+  * @slot:	The memory slot associated with mask
+  * @gfn_offset:	The gfn offset in memory slot
+  * @mask:	The mask of dirty pages at offset 'gfn_offset' in this memory
+  *		slot to be write protected
+  *
+  * Walks bits set in mask write protects the associated pte's. Caller must
+  * acquire kvm_mmu_lock.
+  */
+ void kvm_arch_mmu_write_protect_pt_masked(struct kvm *kvm,
+ 		struct kvm_memory_slot *slot,
+ 		gfn_t gfn_offset, unsigned long mask)
+ {
+ 	phys_addr_t base_gfn = slot->base_gfn + gfn_offset;
+ 	phys_addr_t start = (base_gfn +  __ffs(mask)) << PAGE_SHIFT;
+ 	phys_addr_t end = (base_gfn + __fls(mask) + 1) << PAGE_SHIFT;
+ 
+ 	stage2_wp_range(kvm, start, end);
+ }
+ 
  static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
  			  struct kvm_memory_slot *memslot, unsigned long hva,
  			  unsigned long fault_status)
@@@ -1059,13 -1220,13 +1277,12 @@@
  		if (writable) {
  			kvm_set_s2pte_writable(&new_pte);
  			kvm_set_pfn_dirty(pfn);
+ 			mark_page_dirty(kvm, gfn);
  		}
 -		coherent_cache_guest_page(vcpu, hva, PAGE_SIZE,
 -					  fault_ipa_uncached);
 +		coherent_cache_guest_page(vcpu, pfn, PAGE_SIZE, fault_ipa_uncached);
- 		ret = stage2_set_pte(kvm, memcache, fault_ipa, &new_pte,
- 			pgprot_val(mem_type) == pgprot_val(PAGE_S2_DEVICE));
+ 		ret = stage2_set_pte(kvm, memcache, fault_ipa, &new_pte, flags);
  	}
  
- 
  out_unlock:
  	spin_unlock(&kvm->mmu_lock);
  	kvm_release_pfn_clean(pfn);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kernel/kvmclock.c between commit 5dfd486c4750 ("x86, kvm: Fix
kvm's use of __pa() on percpu areas") from Linus' tree and commit
fe1140cc3694 ("x86: kvmclock: Do not setup kvmclock vsyscall in the
absence of that clock") from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/kernel/kvmclock.c
index 0732f00,b730efa..0000000
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@@ -160,10 -160,14 +160,14 @@@ int kvm_register_clock(char *txt
  {
  	int cpu = smp_processor_id();
  	int low, high, ret;
- 	struct pvclock_vcpu_time_info *src = &hv_clock[cpu].pvti;
+ 	struct pvclock_vcpu_time_info *src;
+ 
+ 	if (!hv_clock)
+ 		return 0;
  
+ 	src = &hv_clock[cpu].pvti;
 -	low = (int)__pa(src) | 1;
 -	high = ((u64)__pa(src) >> 32);
 +	low = (int)slow_virt_to_phys(src) | 1;
 +	high = ((u64)slow_virt_to_phys(src) >> 32);
  	ret = native_write_msr_safe(msr_kvm_system_time, low, high);
  	printk(KERN_INFO "kvm-clock: cpu %d, msr %x:%x, %s\n",
  	       cpu, high, low, txt);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/include/asm/vmx.h between commit af170c5061dd ("UAPI: (Scripted)
Disintegrate arch/x86/include/asm") from Linus' tree (v3.8-rc1) and commit
b0da5bec30ec ("KVM: VMX: add missing exit names to VMX_EXIT_REASONS
array") from the kvm tree.

The section modified by the latter has been moved to
arch/x86/include/uapi/asm/vmx.h, so my fix up patch for that file now is
below and can carry the fix as necessary (no action is required).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 7 Feb 2013 14:15:07 +1100
Subject: [PATCH] x86, apicv: merge fixup for uapi include file split

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/include/uapi/asm/vmx.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 979d03b..2871fcc 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -62,10 +62,12 @@
 #define EXIT_REASON_MCE_DURING_VMENTRY  41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS         44
+#define EXIT_REASON_EOI_INDUCED         45
 #define EXIT_REASON_EPT_VIOLATION       48
 #define EXIT_REASON_EPT_MISCONFIG       49
 #define EXIT_REASON_WBINVD              54
 #define EXIT_REASON_XSETBV              55
+#define EXIT_REASON_APIC_WRITE          56
 #define EXIT_REASON_INVPCID             58
 
 #define VMX_EXIT_REASONS \
@@ -103,7 +105,12 @@
 	{ EXIT_REASON_APIC_ACCESS,           "APIC_ACCESS" }, \
 	{ EXIT_REASON_EPT_VIOLATION,         "EPT_VIOLATION" }, \
 	{ EXIT_REASON_EPT_MISCONFIG,         "EPT_MISCONFIG" }, \
-	{ EXIT_REASON_WBINVD,                "WBINVD" }
+	{ EXIT_REASON_WBINVD,                "WBINVD" }, \
+	{ EXIT_REASON_APIC_WRITE,            "APIC_WRITE" }, \
+	{ EXIT_REASON_EOI_INDUCED,           "EOI_INDUCED" }, \
+	{ EXIT_REASON_INVALID_STATE,         "INVALID_STATE" }, \
+	{ EXIT_REASON_INVD,                  "INVD" }, \
+	{ EXIT_REASON_INVPCID,               "INVPCID" }
 
 
 #endif /* _UAPIVMX_H */
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/include/asm/vmx.h between commit af170c5061dd ("UAPI: (Scripted)
Disintegrate arch/x86/include/asm") from Linus' tree and commits
83d4c286931c ("x86, apicv: add APICv register virtualization support")
and c7c9c56ca26f ("x86, apicv: add virtual interrupt delivery support")
from the kvm tree.

I fixed it up (by applying the merge fix patch below) and can carry the
fix as necessary (no action is required).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sat, 2 Feb 2013 16:43:02 +1100
Subject: [PATCH] x86, apicv: merge fixup for uapi include file split

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/include/uapi/asm/vmx.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 979d03b..9a74505 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -62,10 +62,12 @@
 #define EXIT_REASON_MCE_DURING_VMENTRY  41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS         44
+#define EXIT_REASON_EOI_INDUCED         45
 #define EXIT_REASON_EPT_VIOLATION       48
 #define EXIT_REASON_EPT_MISCONFIG       49
 #define EXIT_REASON_WBINVD              54
 #define EXIT_REASON_XSETBV              55
+#define EXIT_REASON_APIC_WRITE          56
 #define EXIT_REASON_INVPCID             58
 
 #define VMX_EXIT_REASONS \
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kvm/i8259.c between commit 749c59fd15b2 ("KVM: PIC: fix use of
uninitialised variable") from Linus' tree and commit ec798660cf72 ("KVM:
cleanup pic reset") from the kvm tree.

The latter removed the code fixed by the former, so I just did that (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
Documentation/virtual/kvm/api.txt between commit f36992e31284 ("KVM: Add
missing KVM_IRQFD API documentation") from Linus' tree and commit
32fad281c068 ("KVM: PPC: Book3S HV: Make the guest hash table size
configurable") from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc Documentation/virtual/kvm/api.txt
index 2c99483,310fe50..0000000
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -1930,22 -1930,41 +1930,56 @@@ The "pte_enc" field provides a value th
  PTE's RPN field (ie, it needs to be shifted left by 12 to OR it
  into the hash PTE second double word).
  
 +4.75 KVM_IRQFD
  
 -4.75 KVM_PPC_ALLOCATE_HTAB
 +Capability: KVM_CAP_IRQFD
 +Architectures: x86
 +Type: vm ioctl
 +Parameters: struct kvm_irqfd (in)
 +Returns: 0 on success, -1 on error
 +
 +Allows setting an eventfd to directly trigger a guest interrupt.
 +kvm_irqfd.fd specifies the file descriptor to use as the eventfd and
 +kvm_irqfd.gsi specifies the irqchip pin toggled by this event.  When
 +an event is tiggered on the eventfd, an interrupt is injected into
 +the guest using the specified gsi pin.  The irqfd is removed using
 +the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
 +and kvm_irqfd.gsi.
 +
++4.76 KVM_PPC_ALLOCATE_HTAB
+ 
+ Capability: KVM_CAP_PPC_ALLOC_HTAB
+ Architectures: powerpc
+ Type: vm ioctl
+ Parameters: Pointer to u32 containing hash table order (in/out)
+ Returns: 0 on success, -1 on error
+ 
+ This requests the host kernel to allocate an MMU hash table for a
+ guest using the PAPR paravirtualization interface.  This only does
+ anything if the kernel is configured to use the Book 3S HV style of
+ virtualization.  Otherwise the capability doesn't exist and the ioctl
+ returns an ENOTTY error.  The rest of this description assumes Book 3S
+ HV.
+ 
+ There must be no vcpus running when this ioctl is called; if there
+ are, it will do nothing and return an EBUSY error.
+ 
+ The parameter is a pointer to a 32-bit unsigned integer variable
+ containing the order (log base 2) of the desired size of the hash
+ table, which must be between 18 and 46.  On successful return from the
+ ioctl, it will have been updated with the order of the hash table that
+ was allocated.
+ 
+ If no hash table has been allocated when any vcpu is asked to run
+ (with the KVM_RUN ioctl), the host kernel will allocate a
+ default-sized hash table (16 MB).
+ 
+ If this ioctl is called when a hash table has already been allocated,
+ the kernel will clear out the existing hash table (zero all HPTEs) and
+ return the hash table order in the parameter.  (If the guest is using
+ the virtualized real-mode area (VRMA) facility, the kernel will
+ re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.)
+ 
  
  5. The kvm_run structure
  ------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in kernel/fork.c
between commit 34441427aab4bdb3069a4ffcda69a99357abcb2e ("revert "procfs:
provide stack information for threads" and its fixup commits") from
Linus' tree and commit faa4602e47690fb11221e00f9b9697c8dc0d4b19 ("x86,
perf, bts, mm: Delete the never used BTS-ptrace code") from the kvm tree (via
a merge of part of the tip tree).

Just context changes.  I fixed it up (see below) and can carry the fix
for a while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/fork.c
index 4c14942,5d3592d..0000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -1111,9 -1111,8 +1111,7 @@@ static struct task_struct *copy_process
  	p->memcg_batch.do_batch = 0;
  	p->memcg_batch.memcg = NULL;
  #endif
 -	p->stack_start = stack_start;
  
- 	p->bts = NULL;
- 
  	/* Perform scheduler related setup. Assign this task to a CPU. */
  	sched_fork(p, clone_flags);
  

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Marcelo Tosatti]

On Wed, Jan 27, 2010 at 12:57:30PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in
> arch/x86/kvm/x86.c between commit
> 36cb93fd6b6bf7e9163a69a8bf20207aed5fea44 ("KVM: x86: Fix probable memory
> leak of vcpu->arch.mce_banks") from Linus' tree and commit
> kvm_arch_vcpu_uninit ("KVM: switch vcpu context to use SRCU") from the
> kvm tree.
> 
> I fixed it up (I think ... see below) and can carry the fix for a while.

Stephen,

The merge below is correct. Its also present in commit

d3b54d01b94f6825717ef1d02afc7c295bcce89e

of kvm.git.

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/x86/kvm/x86.c
> index 1ddcad4,a311751..0000000
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@@ -5089,11 -5468,12 +5469,13 @@@ fail
>   
>   void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
>   {
> + 	int idx;
> + 
>  +	kfree(vcpu->arch.mce_banks);
>   	kvm_free_lapic(vcpu);
> - 	down_read(&vcpu->kvm->slots_lock);
> + 	idx = srcu_read_lock(&vcpu->kvm->srcu);
>   	kvm_mmu_destroy(vcpu);
> - 	up_read(&vcpu->kvm->slots_lock);
> + 	srcu_read_unlock(&vcpu->kvm->srcu, idx);
>   	free_page((unsigned long)vcpu->arch.pio_data);
>   }
>   

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kvm/x86.c between commit
36cb93fd6b6bf7e9163a69a8bf20207aed5fea44 ("KVM: x86: Fix probable memory
leak of vcpu->arch.mce_banks") from Linus' tree and commit
kvm_arch_vcpu_uninit ("KVM: switch vcpu context to use SRCU") from the
kvm tree.

I fixed it up (I think ... see below) and can carry the fix for a while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/kvm/x86.c
index 1ddcad4,a311751..0000000
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@@ -5089,11 -5468,12 +5469,13 @@@ fail
  
  void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
  {
+ 	int idx;
+ 
 +	kfree(vcpu->arch.mce_banks);
  	kvm_free_lapic(vcpu);
- 	down_read(&vcpu->kvm->slots_lock);
+ 	idx = srcu_read_lock(&vcpu->kvm->srcu);
  	kvm_mmu_destroy(vcpu);
- 	up_read(&vcpu->kvm->slots_lock);
+ 	srcu_read_unlock(&vcpu->kvm->srcu, idx);
  	free_page((unsigned long)vcpu->arch.pio_data);
  }
  

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
arch/powerpc/kvm/timing.h between commit
38634e6769920929385f1ffc8820dc3e893cc630 ("powerpc/kvm: Remove
problematic BUILD_BUG_ON statement") from Linus' tree and commit
8976402d633b79683667c44ca8252f9b26eebe71 ("KVM: powerpc: Fix BUILD_BUG_ON
condition") from the kvm tree.

Just context changes.  I fixed it up (see below) and can carry it for a
while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/powerpc/kvm/timing.h
index 806ef67,a550f0f..0000000
--- a/arch/powerpc/kvm/timing.h
+++ b/arch/powerpc/kvm/timing.h
@@@ -48,11 -48,7 +48,11 @@@ static inline void kvmppc_set_exit_type
  static inline void kvmppc_account_exit_stat(struct kvm_vcpu *vcpu, int type)
  {
  	/* type has to be known at build time for optimization */
 +
 +	/* The BUILD_BUG_ON below breaks in funny ways, commented out
 +	 * for now ... -BenH
- 	BUILD_BUG_ON(__builtin_constant_p(type));
+ 	BUILD_BUG_ON(!__builtin_constant_p(type));
 +	*/
  	switch (type) {
  	case EXT_INTR_EXITS:
  		vcpu->stat.ext_intr_exits++;

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Davide Libenzi]

On Wed, 1 Jul 2009, Gregory Haskins wrote:

> Just to be clear: the final form will need to be wake_up_poll(), not
> wake_up_locked_poll.

Yep, sorry I missed that one.


- Davide

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

Avi Kivity wrote:
> On 07/01/2009 10:10 AM, Davide Libenzi wrote:
>> On Wed, 1 Jul 2009, Stephen Rothwell wrote:
>>
>>   
>>> Hi Avi,
>>>
>>> Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
>>> between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
>>> revised interface and cleanups") from Linus' tree and commit
>>> 28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
>>> notified about the eventfd file* going away") from the kvm tree.
>>>
>>> Overlapping changes.  I fixed it up (see below), but don't know if this
>>> is the correct fix.
>>>
>>> -- 
>>> Cheers,
>>> Stephen Rothwell                    sfr@canb.auug.org.au
>>>
>>> diff --cc fs/eventfd.c
>>> index 31d12de,72f5f8d..0000000
>>> --- a/fs/eventfd.c
>>> +++ b/fs/eventfd.c
>>> @@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
>>>    {
>>>        struct eventfd_ctx *ctx = file->private_data;
>>>
>>> -     wake_up_poll(&ctx->wqh, POLLHUP);
>>> +     /*
>>> +      * No need to hold the lock here, since we are on the file
>>> cleanup
>>> +      * path and the ones still attached to the wait queue will be
>>> +      * serialized by wake_up_locked_poll().
>>> +      */
>>> +     wake_up_locked_poll(&ctx->wqh, POLLHUP);
>>>   -    kfree(ctx);
>>>   +    eventfd_ctx_put(ctx);
>>>        return 0;
>>>    }
>>>      
>>
>> That's fine.
>> There are a couple of extra spaces before the last two -+ in that patch
>> though ;)
>>    
>
> No, that's a git N-way diff format.  The first column shows the
> changes relative to mainline by kvm.git, and the second the changes to
> kvm.git made by mainline.
>
> I've merged and will push soon, which will resolve the conflict, but I
> think the patch wake_up_locked_poll() is better off in mainline rather
> than kvm.git.

Just to be clear: the final form will need to be wake_up_poll(), not
wake_up_locked_poll.  However, I think what Steven did was optimal
because converting to the locked form without coordinating with kvm.git
would break bisectability.

In the irqfd-fixes series, I had 3 patches related to this situation
(1/5 to prepare to change, 2/5 was Davide's patch, and 3/5 did the final
change-over).  Now that the vast majority of Davide's work is in
mainline+kvm.git, here is my proposal:

*) drop 2/5 (already upstream, sans the locked POLLHUP)
*) fold 1/5 + 3/5, and add new fs/eventfd.c hunk to convert to locked
variant
*) drop 5/5

Sound good?
-Greg




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

Avi Kivity wrote:
> On 07/01/2009 10:10 AM, Davide Libenzi wrote:
>> On Wed, 1 Jul 2009, Stephen Rothwell wrote:
>>
>>   
>>> Hi Avi,
>>>
>>> Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
>>> between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
>>> revised interface and cleanups") from Linus' tree and commit
>>> 28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
>>> notified about the eventfd file* going away") from the kvm tree.
>>>
>>> Overlapping changes.  I fixed it up (see below), but don't know if this
>>> is the correct fix.
>>>
>>> -- 
>>> Cheers,
>>> Stephen Rothwell                    sfr@canb.auug.org.au
>>>
>>> diff --cc fs/eventfd.c
>>> index 31d12de,72f5f8d..0000000
>>> --- a/fs/eventfd.c
>>> +++ b/fs/eventfd.c
>>> @@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
>>>    {
>>>        struct eventfd_ctx *ctx = file->private_data;
>>>
>>> -     wake_up_poll(&ctx->wqh, POLLHUP);
>>> +     /*
>>> +      * No need to hold the lock here, since we are on the file
>>> cleanup
>>> +      * path and the ones still attached to the wait queue will be
>>> +      * serialized by wake_up_locked_poll().
>>> +      */
>>> +     wake_up_locked_poll(&ctx->wqh, POLLHUP);
>>>   -    kfree(ctx);
>>>   +    eventfd_ctx_put(ctx);
>>>        return 0;
>>>    }
>>>      
>>
>> That's fine.
>> There are a couple of extra spaces before the last two -+ in that patch
>> though ;)
>>    
>
> No, that's a git N-way diff format.  The first column shows the
> changes relative to mainline by kvm.git, and the second the changes to
> kvm.git made by mainline.
>
> I've merged and will push soon, which will resolve the conflict, but I
> think the patch wake_up_locked_poll() is better off in mainline rather
> than kvm.git.

Just to be clear: the final form will need to be wake_up_poll(), not
wake_up_locked_poll.  However, I think what Steven did was optimal
because converting to the locked form without coordinating with kvm.git
would break bisectability.

In the irqfd-fixes series, I had 3 patches related to this situation
(1/5 to prepare to change, 2/5 was Davide's patch, and 3/5 did the final
change-over).  Now that the vast majority of Davide's work is in
mainline+kvm.git, here is my proposal:

*) drop 2/5 (already upstream, sans the locked POLLHUP)
*) fold 1/5 + 3/5, and add new fs/eventfd.c hunk to convert to locked
variant
*) drop 5/5

Sound good?
-Greg




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Avi Kivity]

On 07/01/2009 10:10 AM, Davide Libenzi wrote:
> On Wed, 1 Jul 2009, Stephen Rothwell wrote:
>
>    
>> Hi Avi,
>>
>> Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
>> between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
>> revised interface and cleanups") from Linus' tree and commit
>> 28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
>> notified about the eventfd file* going away") from the kvm tree.
>>
>> Overlapping changes.  I fixed it up (see below), but don't know if this
>> is the correct fix.
>>
>> -- 
>> Cheers,
>> Stephen Rothwell                    sfr@canb.auug.org.au
>>
>> diff --cc fs/eventfd.c
>> index 31d12de,72f5f8d..0000000
>> --- a/fs/eventfd.c
>> +++ b/fs/eventfd.c
>> @@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
>>    {
>>    	struct eventfd_ctx *ctx = file->private_data;
>>
>> - 	wake_up_poll(&ctx->wqh, POLLHUP);
>> + 	/*
>> + 	 * No need to hold the lock here, since we are on the file cleanup
>> + 	 * path and the ones still attached to the wait queue will be
>> + 	 * serialized by wake_up_locked_poll().
>> + 	 */
>> + 	wake_up_locked_poll(&ctx->wqh, POLLHUP);
>>   -	kfree(ctx);
>>   +	eventfd_ctx_put(ctx);
>>    	return 0;
>>    }
>>      
>
> That's fine.
> There are a couple of extra spaces before the last two -+ in that patch
> though ;)
>    

No, that's a git N-way diff format.  The first column shows the changes 
relative to mainline by kvm.git, and the second the changes to kvm.git 
made by mainline.

I've merged and will push soon, which will resolve the conflict, but I 
think the patch wake_up_locked_poll() is better off in mainline rather 
than kvm.git.

-- 
error compiling committee.c: too many arguments to function

Re: linux-next: manual merge of the kvm tree with Linus' tree

[Davide Libenzi]

On Wed, 1 Jul 2009, Stephen Rothwell wrote:

> Hi Avi,
> 
> Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
> between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
> revised interface and cleanups") from Linus' tree and commit
> 28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
> notified about the eventfd file* going away") from the kvm tree.
> 
> Overlapping changes.  I fixed it up (see below), but don't know if this
> is the correct fix.
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc fs/eventfd.c
> index 31d12de,72f5f8d..0000000
> --- a/fs/eventfd.c
> +++ b/fs/eventfd.c
> @@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
>   {
>   	struct eventfd_ctx *ctx = file->private_data;
>   
> - 	wake_up_poll(&ctx->wqh, POLLHUP);
> + 	/*
> + 	 * No need to hold the lock here, since we are on the file cleanup
> + 	 * path and the ones still attached to the wait queue will be
> + 	 * serialized by wake_up_locked_poll().
> + 	 */
> + 	wake_up_locked_poll(&ctx->wqh, POLLHUP);
>  -	kfree(ctx);
>  +	eventfd_ctx_put(ctx);
>   	return 0;
>   }

That's fine.
There are a couple of extra spaces before the last two -+ in that patch 
though ;)


- Davide

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
revised interface and cleanups") from Linus' tree and commit
28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
notified about the eventfd file* going away") from the kvm tree.

Overlapping changes.  I fixed it up (see below), but don't know if this
is the correct fix.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/eventfd.c
index 31d12de,72f5f8d..0000000
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
  {
  	struct eventfd_ctx *ctx = file->private_data;
  
- 	wake_up_poll(&ctx->wqh, POLLHUP);
+ 	/*
+ 	 * No need to hold the lock here, since we are on the file cleanup
+ 	 * path and the ones still attached to the wait queue will be
+ 	 * serialized by wake_up_locked_poll().
+ 	 */
+ 	wake_up_locked_poll(&ctx->wqh, POLLHUP);
 -	kfree(ctx);
 +	eventfd_ctx_put(ctx);
  	return 0;
  }