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? 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
