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 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
