From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Add CPUID support for VIA CPU Date: Wed, 13 Apr 2011 14:32:47 +0300 Message-ID: <4DA589DF.8060002@redhat.com> References: <4DA565D8.8050504@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, kvm@vger.kernel.org To: BrillyWu@viatech.com.cn Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8548 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758482Ab1DMLcu (ORCPT ); Wed, 13 Apr 2011 07:32:50 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 04/13/2011 02:05 PM, BrillyWu@viatech.com.cn 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. > >> @@ -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. > 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. > 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. -- error compiling committee.c: too many arguments to function