From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH 0/2] kvm: disable virtualization on kdump Date: Wed, 29 Oct 2008 18:33:39 -0700 Message-ID: References: <4904676F.3020706@redhat.com> <490487C1.1010707@redhat.com> <20081026213927.GF23893@blackpad> <49058645.9010005@redhat.com> <20081027122808.GH23893@blackpad> <4905C9ED.807@redhat.com> <20081028194530.GK23893@blackpad> <49082FD0.3040009@redhat.com> <4908975A.7050900@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eduardo Habkost , Simon Horman , kexec@lists.infradead.org, kvm@vger.kernel.org, Andrew Morton , Vivek Goyal , Haren Myneni To: Avi Kivity Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]:35022 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbYJ3Bev (ORCPT ); Wed, 29 Oct 2008 21:34:51 -0400 In-Reply-To: <4908975A.7050900@redhat.com> (Avi Kivity's message of "Wed, 29 Oct 2008 19:03:22 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity writes: > Eric W. Biederman wrote: >> Most of the reason I was wondering is that the cpu hardware probing >> largely seems to be a duplicate of what we have in the core for >> probing cpu capabilities already, and could likely be made smaller >> by building upon the existing codebase. >> >> > > We use the core cpuid functions, or are you referring to something else? I was referring to the arch/x86/kernel/cpu/* and arch/x86/include/asm/cpufeature.h The core functions that are responsible for detecting all of the cpu features, and disabling them if there are cpu errata. The usual pattern is that code does all of the magic detection logic and then the code that would use it would just need to test: cpu_has_vmx or cpu_has_svm. At least in part that allows us to show the working cpu features in /proc/cpuinfo. >>> svm can writeback into memory at odd times if we don't do this, and the cost > is >>> small - clear a bit in EFER. There's no reason to be lazy. >>> >> >> Especially if we can clear that bit unconditionally (when >> EFER is present) I'm all for it. >> > > That is the case. Cool. I forget if we have to test for EFER on 32bit, or if we can just wrmsr and be done with it. Regardless that sounds easy to do on the kexec path. Eric