From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue Date: Mon, 25 Feb 2008 19:40:05 +0200 Message-ID: <47C2FD75.4080907@qumranet.com> References: <10EA09EFD8728347A513008B6B0DA77A02CFD20F@pdsmsx411.ccr.corp.intel.com> <200802251731.57297.sheng.yang@intel.com> <47C28BA5.1010706@qumranet.com> <47C29C2F.4070907@qumranet.com> <3BEBF809-50B8-4D30-BE27-45BA4FC4D248@csgraf.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net To: Alexander Graf Return-path: In-Reply-To: <3BEBF809-50B8-4D30-BE27-45BA4FC4D248@csgraf.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Alexander Graf wrote: > > The ebx store was done because of PIC code, which does not allow ebx > to get clobbered. If we are not in PIC code, =r contains ebx as GPR > though, so the assumption that ebx needs to be restored was wrong > then. This new version only enables the store/restore code if i386 and > PIC code are used. There is no need to distinguish between x86_64 and > i386 for the other cases. > > So does this version work? > It probably will, but it seems fragile to depend on the details of PIC. I committed something more generic: #ifdef __x86_64__ asm volatile("cpuid" : "=a"(vec[0]), "=b"(vec[1]), "=c"(vec[2]), "=d"(vec[3]) : "0"(function) : "cc"); #else asm volatile("pusha \n\t" "cpuid \n\t" "mov %%eax, 0(%1) \n\t" "mov %%ebx, 4(%1) \n\t" "mov %%ecx, 8(%1) \n\t" "mov %%edx, 12(%1) \n\t" "popa" : "a"(function), "S"(vec) : "memory", "cc"); #endif -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/