On Thu, Feb 11, 2021, Paolo Bonzini wrote:
> On 11/02/21 01:55, Sean Christopherson wrote:
> > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > > index ee4ac2618ec59..c6e5b026bbfe8 100644
> > > --- a/virt/kvm/kvm_main.c
> > > +++ b/virt/kvm/kvm_main.c
> > > @@ -307,6 +307,7 @@ bool kvm_make_all_cpus_request(struct kvm *kvm, unsigned int req)
> > > {
> > > return kvm_make_all_cpus_request_except(kvm, req, NULL);
> > > }
> > > +EXPORT_SYMBOL_GPL(kvm_make_all_cpus_request);
> > If we move enable_pml into x86.c then this export and several of the kvm_x86_ops
> > go away. I know this because I have a series I was about to send that does that,
> > among several other things. I suspect that kvm->arch.pml_enabled could also go
> > away, but that's just a guess.
>
> I don't like the idea of moving enable_pml into x86.c, but I'm ready to be
> convinced otherwise. In any case, for sure you can _check_ enable_pml from
> x86.c via kvm_x86_ops.flush_log_dirty or kvm_x86_ops.cpu_dirty_log_size.
Ya, after taking another look at my series, exposing enable_pml isn't necessary.
What I really dislike is bouncing through VMX and exporting MMU functions for
no real benefit. The x86/MMU functions/behavior are tightly coupled to VMX's
implementation, bouncing through kvm_x86_ops doesn't magically decouple things.
Anyways, kvm_x86_ops.cpu_dirty_log_size can be change to a simple integer instead
of a callback function, and with that change I'm happy using cpu_dirty_log_size
as the check with x86.c/mmu.c to determine whether or not hardware dirty logging
is supported.
Thanks for the early sanity check :-)
