Message ID | 20200324094154.32352-1-joro@8bytes.org (mailing list archive) |
---|---|
Headers | show |
Series | KVM: SVM: Move and split up svm.c | expand |
On 24/03/20 10:41, Joerg Roedel wrote: > Hi, > > here is a patch-set agains kvm/queue which moves svm.c into its own > subdirectory arch/x86/kvm/svm/ and splits moves parts of it into > separate source files: > > - The parts related to nested SVM to nested.c > > - AVIC implementation to avic.c > > - The SEV parts to sev.c > > I have tested the changes in a guest with and without SEV. > > Please review. > > Thanks, > > Joerg > > Joerg Roedel (4): > kVM SVM: Move SVM related files to own sub-directory > KVM: SVM: Move Nested SVM Implementation to nested.c > KVM: SVM: Move AVIC code to separate file > KVM: SVM: Move SEV code to separate file > > arch/x86/kvm/Makefile | 2 +- > arch/x86/kvm/svm/avic.c | 1025 ++++ > arch/x86/kvm/svm/nested.c | 823 ++++ > arch/x86/kvm/{pmu_amd.c => svm/pmu.c} | 0 > arch/x86/kvm/svm/sev.c | 1178 +++++ > arch/x86/kvm/{ => svm}/svm.c | 6546 ++++++------------------- > arch/x86/kvm/svm/svm.h | 491 ++ > 7 files changed, 5106 insertions(+), 4959 deletions(-) > create mode 100644 arch/x86/kvm/svm/avic.c > create mode 100644 arch/x86/kvm/svm/nested.c > rename arch/x86/kvm/{pmu_amd.c => svm/pmu.c} (100%) > create mode 100644 arch/x86/kvm/svm/sev.c > rename arch/x86/kvm/{ => svm}/svm.c (56%) > create mode 100644 arch/x86/kvm/svm/svm.h > Queued, thanks (only cursorily reviewed for now). Paolo
Hello Paolo, I am going to submit v5 of the SEV live migration patch-set in a couple of days and my patch-set is based on the single svm.c file, so do i need to rebase my patch-set gainst this queued patch ? Thanks, Ashish On Tue, Mar 24, 2020 at 12:33:17PM +0100, Paolo Bonzini wrote: > On 24/03/20 10:41, Joerg Roedel wrote: > > Hi, > > > > here is a patch-set agains kvm/queue which moves svm.c into its own > > subdirectory arch/x86/kvm/svm/ and splits moves parts of it into > > separate source files: > > > > - The parts related to nested SVM to nested.c > > > > - AVIC implementation to avic.c > > > > - The SEV parts to sev.c > > > > I have tested the changes in a guest with and without SEV. > > > > Please review. > > > > Thanks, > > > > Joerg > > > > Joerg Roedel (4): > > kVM SVM: Move SVM related files to own sub-directory > > KVM: SVM: Move Nested SVM Implementation to nested.c > > KVM: SVM: Move AVIC code to separate file > > KVM: SVM: Move SEV code to separate file > > > > arch/x86/kvm/Makefile | 2 +- > > arch/x86/kvm/svm/avic.c | 1025 ++++ > > arch/x86/kvm/svm/nested.c | 823 ++++ > > arch/x86/kvm/{pmu_amd.c => svm/pmu.c} | 0 > > arch/x86/kvm/svm/sev.c | 1178 +++++ > > arch/x86/kvm/{ => svm}/svm.c | 6546 ++++++------------------- > > arch/x86/kvm/svm/svm.h | 491 ++ > > 7 files changed, 5106 insertions(+), 4959 deletions(-) > > create mode 100644 arch/x86/kvm/svm/avic.c > > create mode 100644 arch/x86/kvm/svm/nested.c > > rename arch/x86/kvm/{pmu_amd.c => svm/pmu.c} (100%) > > create mode 100644 arch/x86/kvm/svm/sev.c > > rename arch/x86/kvm/{ => svm}/svm.c (56%) > > create mode 100644 arch/x86/kvm/svm/svm.h > > > > Queued, thanks (only cursorily reviewed for now). > > Paolo >
On Tue, Mar 24, 2020 at 10:41:50AM +0100, Joerg Roedel wrote: > Hi, > > here is a patch-set agains kvm/queue which moves svm.c into its own > subdirectory arch/x86/kvm/svm/ and splits moves parts of it into > separate source files: What are people's thoughts on using "arch/x86/kvm/{amd,intel}" instead of "arch/x86/kvm/{svm,vmx}"? Maybe this won't be an issue for AMD/SVM, but on the Intel/VMX side, there is stuff in the pipeline that makes using "vmx" for the sub-directory quite awkward. I wasn't planning on proposing the rename (from vmx->intel) until I could justify _why_, but perhaps it makes sense to bundle all the pain of a reorganizing code into a single kernel version?
On Tue, Mar 24, 2020 at 11:30 AM Sean Christopherson <sean.j.christopherson@intel.com> wrote: > > On Tue, Mar 24, 2020 at 10:41:50AM +0100, Joerg Roedel wrote: > > Hi, > > > > here is a patch-set agains kvm/queue which moves svm.c into its own > > subdirectory arch/x86/kvm/svm/ and splits moves parts of it into > > separate source files: > > What are people's thoughts on using "arch/x86/kvm/{amd,intel}" instead of > "arch/x86/kvm/{svm,vmx}"? Maybe this won't be an issue for AMD/SVM, but on > the Intel/VMX side, there is stuff in the pipeline that makes using "vmx" > for the sub-directory quite awkward. I wasn't planning on proposing the > rename (from vmx->intel) until I could justify _why_, but perhaps it makes > sense to bundle all the pain of a reorganizing code into a single kernel > version? Doesn't VIA have some CPUs that implement VMX?
On Tue, Mar 24, 2020 at 11:42:21AM -0700, Jim Mattson wrote: > On Tue, Mar 24, 2020 at 11:30 AM Sean Christopherson > <sean.j.christopherson@intel.com> wrote: > > > > On Tue, Mar 24, 2020 at 10:41:50AM +0100, Joerg Roedel wrote: > > > Hi, > > > > > > here is a patch-set agains kvm/queue which moves svm.c into its own > > > subdirectory arch/x86/kvm/svm/ and splits moves parts of it into > > > separate source files: > > > > What are people's thoughts on using "arch/x86/kvm/{amd,intel}" instead of > > "arch/x86/kvm/{svm,vmx}"? Maybe this won't be an issue for AMD/SVM, but on > > the Intel/VMX side, there is stuff in the pipeline that makes using "vmx" > > for the sub-directory quite awkward. I wasn't planning on proposing the > > rename (from vmx->intel) until I could justify _why_, but perhaps it makes > > sense to bundle all the pain of a reorganizing code into a single kernel > > version? > > Doesn't VIA have some CPUs that implement VMX? Yes (and this is why I didn't want broach this subject without being able to go into details). On the other hand, the module is kvm_intel...
On Tue, Mar 24, 2020 at 11:30:07AM -0700, Sean Christopherson wrote: > What are people's thoughts on using "arch/x86/kvm/{amd,intel}" instead of > "arch/x86/kvm/{svm,vmx}"? Maybe this won't be an issue for AMD/SVM, but on > the Intel/VMX side, there is stuff in the pipeline that makes using "vmx" > for the sub-directory quite awkward. I wasn't planning on proposing the > rename (from vmx->intel) until I could justify _why_, but perhaps it makes > sense to bundle all the pain of a reorganizing code into a single kernel > version? I am fine either way, naming the directory amd/ or svm/ doesn't make a big difference. Regards, Joerg
On 24/03/20 19:55, Sean Christopherson wrote: >> here is a patch-set agains kvm/queue which moves svm.c into its own >> subdirectory arch/x86/kvm/svm/ and splits moves parts of it into >> separate source files: > What are people's thoughts on using "arch/x86/kvm/{amd,intel}" instead of > "arch/x86/kvm/{svm,vmx}"? Maybe this won't be an issue for AMD/SVM, but on > the Intel/VMX side, there is stuff in the pipeline that makes using "vmx" > for the sub-directory quite awkward. I wasn't planning on proposing the > rename (from vmx->intel) until I could justify _why_, but perhaps it makes > sense to bundle all the pain of a reorganizing code into a single kernel > version? For now I would keep it svm and vmx. I would expect that other Intel three-letter acronyms would still use most of the vmx concepts (e.g. VMCS) not unlike Hyper-V's eVMCS, so the existing directory name makes sense (possibly with vmx.c split further to something like vmx-common.c or intel-common.c). Paolo