public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat•com>
To: Stephen Rothwell <sfr@canb•auug.org.au>, KVM <kvm@vger•kernel.org>
Cc: Linux Next Mailing List <linux-next@vger•kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
	Haiwei Li <lihaiwei.kernel@gmail•com>,
	Tom Lendacky <thomas.lendacky@amd•com>,
	Joerg Roedel <jroedel@suse•de>
Subject: Re: linux-next: manual merge of the kvm tree with Linus' tree
Date: Thu, 2 Apr 2020 12:44:43 +0200	[thread overview]
Message-ID: <649ebb8f-d8c4-b893-eddb-9c0a00bf30e0@redhat.com> (raw)
In-Reply-To: <20200402133637.296e70a9@canb.auug.org.au>


[-- 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 --]

  parent reply	other threads:[~2020-04-02 10:44 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02  2:36 linux-next: manual merge of the kvm tree with Linus' tree Stephen Rothwell
2020-04-02  8:15 ` Paolo Bonzini
2020-04-02 10:44 ` Paolo Bonzini [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-10-10  1:31 Stephen Rothwell
2022-07-13  6:02 Stephen Rothwell
2022-07-13  6:09 ` Paolo Bonzini
2022-06-09  0:33 Stephen Rothwell
2022-05-13  3:53 Stephen Rothwell
2022-03-30 23:42 Stephen Rothwell
2021-04-22  4:29 linux-next: manual merge of the kvm tree with Linus tree Stephen Rothwell
2020-12-17  2:56 linux-next: manual merge of the kvm tree with Linus' tree Stephen Rothwell
2020-01-24  2:57 Stephen Rothwell
2019-05-17  1:16 Stephen Rothwell
2019-05-17  1:10 Stephen Rothwell
2019-05-17  1:04 Stephen Rothwell
2019-03-04  2:50 Stephen Rothwell
2018-10-18  2:37 Stephen Rothwell
2018-08-15  4:24 Stephen Rothwell
2018-08-15  4:20 Stephen Rothwell
2018-08-06  5:21 Stephen Rothwell
2018-06-04  7:04 Stephen Rothwell
2018-02-05  2:06 Stephen Rothwell
2018-02-05  1:06 Stephen Rothwell
2018-02-01  1:55 Stephen Rothwell
2018-02-01 10:47 ` Christoffer Dall
2018-02-01 13:22   ` Stephen Rothwell
2018-02-01 14:05     ` Christoffer Dall
2018-02-01 14:21     ` Paolo Bonzini
2018-02-01 15:22       ` Radim Krčmář
2018-02-01 15:30         ` Paolo Bonzini
2018-02-02  0:20         ` Stephen Rothwell
2018-02-02 17:22           ` Radim Krčmář
2018-01-25 21:07 Stephen Rothwell
2018-01-17  3:48 Stephen Rothwell
2018-01-17 11:45 ` Thomas Gleixner
2018-01-17 12:17   ` Paolo Bonzini
2018-01-17 12:23     ` Thomas Gleixner
2018-01-17 12:35       ` Paolo Bonzini
2018-01-17 12:37         ` Thomas Gleixner
2018-01-17 12:43       ` Stephen Rothwell
2018-01-17 12:53         ` Thomas Gleixner
2018-01-29  4:02           ` Stephen Rothwell
2018-01-29 10:35             ` Paolo Bonzini
2017-08-25  4:34 Stephen Rothwell
2017-09-04  6:04 ` Stephen Rothwell
2016-07-27  4:50 Stephen Rothwell
2015-05-25  7:25 Stephen Rothwell
2015-05-25 14:11 ` Paolo Bonzini
2015-02-09  6:11 Stephen Rothwell
2015-02-02  5:05 Stephen Rothwell
2015-02-02  5:03 Stephen Rothwell
2013-03-01  2:51 Stephen Rothwell
2013-02-07  3:20 Stephen Rothwell
2013-02-02  5:52 Stephen Rothwell
2012-09-12  4:33 Stephen Rothwell
2012-07-06  5:12 Stephen Rothwell
2010-05-13  3:43 Stephen Rothwell
2010-01-27  1:57 Stephen Rothwell
2010-01-27 16:38 ` Marcelo Tosatti
2009-11-06  0:21 Stephen Rothwell
2009-07-01  4:57 Stephen Rothwell
2009-07-01  7:10 ` Davide Libenzi
     [not found]   ` <4A4B1106.8000506@redhat.com>
2009-07-01 12:30     ` Gregory Haskins
2009-07-01 15:11       ` Davide Libenzi
2009-07-01 12:31     ` Gregory Haskins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=649ebb8f-d8c4-b893-eddb-9c0a00bf30e0@redhat.com \
    --to=pbonzini@redhat$(echo .)com \
    --cc=jroedel@suse$(echo .)de \
    --cc=kvm@vger$(echo .)kernel.org \
    --cc=lihaiwei.kernel@gmail$(echo .)com \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=linux-next@vger$(echo .)kernel.org \
    --cc=sfr@canb$(echo .)auug.org.au \
    --cc=thomas.lendacky@amd$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox