On 04/13/2011 02:05 PM, [email protected] wrote: > > >> > > >> + /* cpuid 0xC0000001.edx */ > > >> + const u32 kvm_supported_word5_x86_features = > > >> + F(XSTORE) | F(XSTORE_EN) | F(XCRYPT) | F(XCRYPT_EN) | > > >> + F(ACE2) | F(ACE2_EN) | F(PHE) | F(PHE_EN) | > > >> + F(PMM) | F(PMM_EN); > > >> + > > > > Are all of these features save wrt save/restore? (do they all act > > >on state in standard registers?) Do they need any control register > > >bits to be active or MSRs to configure? > > > These features depend on instructions for the PadLock hardware engine of > > VIA CPU. > > The PadLock instructions just act on standard registers like general X86 > > instructions, and the features have been enabled when the CPU leave the > > factory, so there is no need to activate any control register bits or > > configure MSRs.
> I see there is a dependency on EFLAGS[30]. Does a VM entry clear this bit? > If not, we have to do it ourselves. Yes, PadLock hardware engine has some association with EFLAGS[30], but it just required that the EFLAGS[30] should be set to "0" before using PadLock ACE instructions. It is recommanded that execute instruction sequence "pushf;popf" to clear this bit before using ACE instructions. AFAIK, the VM entry never sets the EFLAGS[30] bit, so it seems that we do not have to do it ourselves. > > >> @@ -2484,6 +2504,17 @@ static int kvm_dev_ioctl_get_supported_c > > >> > > >> r = -E2BIG; > > >> if (nent>= cpuid->nent) > > >> + goto out_free; > > >> + > > >> + /* Add support for Centaur's CPUID instruction. */ > > >> + do_cpuid_ent(&cpuid_entries[nent], 0xC0000000, 0,&nent, > > >> cpuid->nent); > > > > nent overflow check missing here. Also, should probably skip if not a > > > Via. > > > If not a VIA, the "limit" will be "0", so the following cycle can not run. > I think Intel defines CPUID to return the highest standard leaf, so it will > be equivalent to cpuid(0x1a) or something like that. Yes, you're right. > > Moreover, it seems that there is no method to know whther the CPU is a VIA > > or not in this function. > Can't you check the vendor ID? see boot_cpu_data. Good idea, thank you very much. > > The nent overflow check is put after the cycle like the "0x8000000" case, > > and when on a VIA, the returned "limit" is not large (generally it is > > 0xC0000004), is it neccesary to add a more check here? > Yes, otherwise userspace can supply a buffer that is exactly the wrong size > and cause an overflow. OK, I will add the check. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
