Message ID | 20240131233056.10845-1-pbonzini@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: cleanup linux/kvm.h | expand |
On Wed, Jan 31, 2024, Paolo Bonzini wrote: > More cleanups of KVM's main header: > > * remove thoroughly obsolete APIs > > * move architecture-dependent stuff to uapi/asm/kvm.h > > * small cleanups to __KVM_HAVE_* symbols Do you have any thoughts on how/when you're going to apply this? The kvm.h code movement is likely going to generate conflicts for any new uAPI, e.g. I know Paul's Xen series at least conflicts. A topic branch is probably overkill. Maybe getting this into kvm/next sooner than later so that kvm/next can be used as a base will suffice?
On Wed, Feb 7, 2024 at 3:43 PM Sean Christopherson <seanjc@google.com> wrote: > > On Wed, Jan 31, 2024, Paolo Bonzini wrote: > > More cleanups of KVM's main header: > > > > * remove thoroughly obsolete APIs > > > > * move architecture-dependent stuff to uapi/asm/kvm.h > > > > * small cleanups to __KVM_HAVE_* symbols > > Do you have any thoughts on how/when you're going to apply this? The kvm.h code > movement is likely going to generate conflicts for any new uAPI, e.g. I know Paul's > Xen series at least conflicts. It also conflicts (and was partly motivated by) the SEV API cleanups that I am going to post soon. > A topic branch is probably overkill. Maybe getting this into kvm/next sooner > than later so that kvm/next can be used as a base will suffice? I can do both, a topic branch is free. But if you think this is in the "if it compiles, apply it", then I can take that as Acked-by and apply it today or tomorrow. Paolo
On Thu, Feb 08, 2024, Paolo Bonzini wrote: > On Wed, Feb 7, 2024 at 3:43 PM Sean Christopherson <seanjc@google.com> wrote: > > > > On Wed, Jan 31, 2024, Paolo Bonzini wrote: > > > More cleanups of KVM's main header: > > > > > > * remove thoroughly obsolete APIs > > > > > > * move architecture-dependent stuff to uapi/asm/kvm.h > > > > > > * small cleanups to __KVM_HAVE_* symbols > > > > Do you have any thoughts on how/when you're going to apply this? The kvm.h code > > movement is likely going to generate conflicts for any new uAPI, e.g. I know Paul's > > Xen series at least conflicts. > > It also conflicts (and was partly motivated by) the SEV API cleanups > that I am going to post soon. > > > A topic branch is probably overkill. Maybe getting this into kvm/next sooner > > than later so that kvm/next can be used as a base will suffice? > > I can do both, a topic branch is free. But if you think this is in the > "if it compiles, apply it", then I can take that as Acked-by and apply > it today or tomorrow. Looks like you already created and merged a topic branch, but for giggles: Acked-by: Sean Christopherson <seanjc@google.com>
On Thu, Feb 8, 2024 at 6:10 PM Sean Christopherson <seanjc@google.com> wrote: > > I can do both, a topic branch is free. But if you think this is in the > > "if it compiles, apply it", then I can take that as Acked-by and apply > > it today or tomorrow. > > Looks like you already created and merged a topic branch, but for giggles: Only to kvm/queue to show myself how it would look like... > Acked-by: Sean Christopherson <seanjc@google.com> Thanks! Paolo