lkml.org 
[lkml]   [2008]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 08/16] x86: Emergency virtualization disable function
On Wed, Nov 05, 2008 at 09:33:06AM -0800, Eric W. Biederman wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
>
> > +int set_virt_disable_func(void (*fn)(void))
> > +{
> > + int r = 0;
> > +
> > + spin_lock(&virt_disable_lock);
> > + if (!virt_disable_fn)
> > + rcu_assign_pointer(virt_disable_fn, fn);
> > + else
> > + r = -EEXIST;
> > + spin_unlock(&virt_disable_lock);
> > +
> > + return r;
> > +}
> > +EXPORT_SYMBOL(set_virt_disable_func);
>
> EXPORT_SYMBOL_GPL?
>
> > +EXPORT_SYMBOL(clear_virt_disable_func);
> EXPORT_SYMBOL_GPL?
>
> We are talking a core internal api that should not even
> be exported if KVM is compiled into the kernel.
>
> I have had to tell people NO too many times by that
> wanted to shove code on the kexec on panic path that
> had no business there. I do not want to give
> the least little impression that this is an ok hook
> for the to use. The very specific name helps in
> that regard thank you for that. Having the symbol
> exported GPL would help even more.

Agreed. I will change that if nobody else objects.

>
> Overall I think the code is just barely ok.
>
> I don't like the fact that to run 2-3 instructions per cpu we are two
> function pointers deep. It feels like we have an excess of
> abstraction here on the kvm side.
>
> Is it possible to have the individual kvm modules call
> set_virt_disable_func and clear_virt_disable_func? Instead
> of going through the x86_kvm_ops?
>
> It really feels like we have an excess of abstraction here.

We could move the set_virt_disable_func() calls to vmx.c and svm.c (on
hardware_setup/hardware_unsetup). One could argue that it is sort of a
coincidence that we need the code for both vmx and svm.

Avi, what do you think?

--
Eduardo


\
 
 \ /
  Last update: 2008-11-05 18:55    [W:0.077 / U:12.848 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site