lkml.org 
[lkml]   [2008]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 15/16] kvm: x86: set kdump virt_disable function on initialization
    On Wed, Nov 05, 2008 at 09:26:53AM -0800, Eric W. Biederman wrote:
    > Eduardo Habkost <ehabkost@redhat.com> writes:
    >
    > > Finally implement the virt_disable function for kdump. It will call
    > > kvm_x86_ops->crash_hardware_disable(), that will disable virtualization
    > > extensions on the CPU if it is not disabled yet.
    > >
    > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
    > > ---
    > > arch/x86/kvm/x86.c | 19 ++++++++++++++++++-
    > > 1 files changed, 18 insertions(+), 1 deletions(-)
    > >
    > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
    > > index 049c6a0..9e61baf 100644
    > > --- a/arch/x86/kvm/x86.c
    > > +++ b/arch/x86/kvm/x86.c
    > > @@ -40,6 +40,7 @@
    > > #include <asm/msr.h>
    > > #include <asm/desc.h>
    > > #include <asm/mtrr.h>
    > > +#include <asm/virtext.h>
    > >
    > > #define MAX_IO_MSRS 256
    > > #define CR0_RESERVED_BITS \
    > > @@ -2581,6 +2582,13 @@ int kvm_emulate_pio_string(struct kvm_vcpu *vcpu, struct
    > > kvm_run *run, int in,
    > > }
    > > EXPORT_SYMBOL_GPL(kvm_emulate_pio_string);
    > >
    > > +/* Called at crash time, so we can disable virtualization if needed
    > > + */
    > > +static void crash_hardware_disable(void)
    > > +{
    > > + kvm_x86_ops->crash_hardware_disable(NULL);
    > > +}
    > > +
    > > int kvm_arch_init(void *opaque)
    > > {
    > > int r;
    > > @@ -2605,9 +2613,15 @@ int kvm_arch_init(void *opaque)
    > >
    > > kvm_x86_ops = ops;
    > >
    > > + r = set_virt_disable_func(crash_hardware_disable);
    >
    > Can we make this say:
    > set_virt_disable_func(kvm_x86_ops->crash_hardware_disable);
    >
    > So we can avoid going through 2 levels of function pointers?
    > I find that a little scary in code that might be running
    > at the edge of stack overflow.

    When I've checked this (on x86_64), gcc did tail recursion optimization
    and the call was just a jump to the function, so stack usage shouldn't
    be a problem.

    But I am inclined to agree with you about the excess of abstraction.

    --
    Eduardo


    \
     
     \ /
      Last update: 2008-11-05 18:55    [W:0.024 / U:61.912 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site