From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/4] Fix tboot enabled macro Date: Thu, 27 May 2010 10:36:27 +0200 Message-ID: <4BFE2F0B.9010406@siemens.com> References: <4BFC9686.9050300@redhat.com> <4BFCCCFD.20203@web.de> <4BFCDDFB.9010505@redhat.com> <4BFCFA6F.8030000@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Zachary Amsden , kvm , Gleb Natapov , "Cihula, Joseph" To: "Wang, Shane" Return-path: Received: from david.siemens.de ([192.35.17.14]:23273 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750827Ab0E0Igt (ORCPT ); Thu, 27 May 2010 04:36:49 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Wang, Shane wrote: > Jan Kiszka wrote: >> Wang, Shane wrote: >>> Avi Kivity wrote: >>>> On 05/26/2010 10:25 AM, Jan Kiszka wrote: >>>>> This is for CONFIG_INTEL_TXT enabled? Good point but needs to be >>>>> solved differently. tboot, the variable that is checked by the >>>>> original header, is not exported to modules. I wonder how this >>>>> worked out for you... >>>>> >>>>> Solution should be: hack tboot_enabled to kvm_tboot_enabled and >>>>> unconditionally define that to 0 for older kernels. If tboot is >>>>> actually enabled in hardware, KVM may not load but I'm unsure if >>>>> it's OK to assume tboot == 1 for that case or if that will cause >>>>> breakages if it's off instead - CC'ing the KVM patch author. >>>>> >>>> Worst case it doesn't load. I don't think it's a problem since >>>> enabling tboot will be rare for older kernels. >>> tboot is not 0 if tboot module is run before kernel. >>> If "tboot is enabled in hardware" (I assume you mean if Intel TXT is >>> enabled in hardware) but tboot module is not run or old kernels >>> don't support tboot module, >>> we still have outside_smx bit in feature msr. Why might KVM not load? >> If we have to hard-wire tboot_enabled in kvm-kmod to 0, KVM may not >> test all required bits and erroneously assume VTX would be disabled. >> >> So I wondered what would happen if we hard-wired it to 1, pretending >> that the tboot modules is loaded. Would we gain something without >> loosing on some other end? If not, I would simply leave things as they >> are now (i.e. always assuming tboot absence). >> >> Thanks, >> Jan > > Why is VTX assumed to be disabled? If TXT is on and VT is locked but KVM sees tboot_enabled == 0, it won't check for FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX during setup and may consider VT unavailable. Moreover, if VT is not locked in that case, KVM will also not set FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX during hardware_enable, likely leaving VT off then, no? So my question is: Would it cause any harm to assume TXT being always on, even if it wasn't? Jan > tboot_enabled == 0 but (msr & FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX) == 1 if you have VT enabled. > If you have VT enabled, VMX outside SMX is 1 always. > > Shane -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux