Hi, Avi I'm sorry to reply you a little late. I spent some time on finding information to fix the EFLAGS[30] issue, and I have got it now. Here is some comment from Centaur.: EFLAGS:30 was used on C7 but not by Nano. EFLAGS:30 is undefined for Intel. C7 used it as a way of improving performance by remembering when keyram was valid but it required users to clear the bit (say by PUSHF/POPF) when changing keys for an encryption. There was a whole lot of ucode to make sure that EFLAGS:30 would always be zero on a task switch, to avoid leaking key material (or simply making an error in calculation). In a rational fit of paranoia, we decided that it was safer to always reset the internal keyram at the start of every XCRYPT instruction, which made use of EFLAGS:30 irrelevant. The current docs make no reference to EFLAGS, and they specifically indicate that they supercede all previous documentation. So,the conclusion is: Only VIA C7 CPUs have dependency on EFLAGS[30], but they do not support VT-X technology, so kvm can not run on it and the issue about EFLAGS[30] will not occur. VIA Nano CPUs support VT-X technology and can run kvm, but they have no dependency on EFLAGS[30] (EFLAGS[30] is kept cleared), so the issue about EFLAGS[30] will not appear, too. I'll send you the current document about nano cpu. Brilly 2011-04-21 > > On 04/14/2011 12:54 PM, BrillyWu@xxxxxxxxxxxxxx wrote: > > Thank you very much for telling me where the EFLAGS[30] > might be set > > and cleared. > > In fact, adding the CPUID support into kvm kernel code is just to > > provide correct result for the calling of the > > "kvm_arch_get_supported_cpuid" function in Qemu-kvm application. > > That may not be sufficient for correct operation. > > Consider: > > - guest executes a padlock instruction > - cpu sets EFLAGS[30] > - external interrupt > - VMEXIT (saves EFLAGS in GUEST_RFLAGS with EFLAGS[30] set) > - external interrupt is processed, causes a task switch > - EFLAGS[30] is cleared > - some other process uses padlock instructions, which causes a reload > of key information > - switch back to kvm > - VM entry (loads EFLAGS from GUEST_RFLAGS; still has EFLAGS[30] set) > - guest executes following padlock instruction, doesn't reload key > information > > so I think the code as is causes data corruption. Yes, I agree. But VIA Nano is no longer associated with EFLAGS[30], so the data corruption will not appear. > > > There is no dependency on EFLAGS when calling VIA CPUID instruction. > > > > Before using padlock engine functions, the application first need > > detect is the features exist through cpuid instruction, > then use ACE > > and other instructions such as PHE/RNG/PMM. > > > > And as previously said, only the ACE instructions required that the > > EFLAGS[30] should be set to "0", It is recommanded that execute > > instruction sequence "pushf;popf" to clear this bit before > using ACE > > instructions. > > The problem is that VM entry reloads eflags from saved state and is > not affected by popf. > > > I have re-submitted this patch, please check it. Thanks! > > wrt cpuid it seems reasonable but that's we need to clear the > EFLAGS[30] issue first. > I think the EFLAGS[30] issue is fixed now. > -- > error compiling committee.c: too many arguments to function > > -- > 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 > -- 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
