Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue

Alexander Graf
2008-02-25T12:55:08Z

[-- Attachment #1: Type: text/plain, Size: 4430 bytes --]

On Feb 25, 2008, at 11:45 AM, Avi Kivity wrote:

> Alexander Graf wrote:
>>
>> On Feb 25, 2008, at 10:34 AM, Avi Kivity wrote:
>>
>>> Yang, Sheng wrote:
>>>> On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote:
>>>>
>>>>> Hi, all,
>>>>>
>>>>> This is today's KVM test result against kvm.git
>>>>> 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git
>>>>> 08385e49dcff3585f597870af67301d7659a1ecb.
>>>>>
>>>>> One new issue has been found in today's testing:
>>>>> 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host
>>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=1901208&group_
>>>>>
>>>>> id=180599&atid=893831
>>>>>
>>>>
>>>> A quick bisect shows that the problem caused by "kvm: qemu: fix
>>>> host_cpuid()
>>>> on x86_64".
>>>>
>>>
>>> Yeah, I just found this out the hard way (by trying to debug this --
>>> silly me). The effects were that the "GenuineIntel" in cpuid
>>> identification was corrupted.
>>
>> Could you please execute this source on a computer that fails with
>> the
>> argument "0" (please compile with the same switches as qemu) and give
>> me the results + disassembly?
>
>
> 0000101c <host_cpuid>:
> 101c: 55 push %ebp
> 101d: 89 e5 mov %esp,%ebp
> 101f: 57 push %edi
> 1020: 56 push %esi
> 1021: 53 push %ebx
> 1022: 83 ec 3c sub $0x3c,%esp
> 1025: 89 55 d4 mov %edx,-0x2c(%ebp)
> 1028: 89 de mov %ebx,%esi
> 102a: 0f a2 cpuid
> 102c: 89 db mov %ebx,%ebx
> 102e: 89 f3 mov %esi,%ebx
> 1030: 89 d7 mov %edx,%edi
> 1032: 89 55 e4 mov %edx,-0x1c(%ebp)
> 1035: 8b 55 d4 mov -0x2c(%ebp),%edx
> 1038: 85 d2 test %edx,%edx
> 103a: 89 4d c4 mov %ecx,-0x3c(%ebp)
> 103d: 89 5d d0 mov %ebx,-0x30(%ebp)
> 1040: 89 45 d8 mov %eax,-0x28(%ebp)
> 1043: 89 5d dc mov %ebx,-0x24(%ebp)
> 1046: 89 4d e0 mov %ecx,-0x20(%ebp)
> 1049: 74 05 je 1050 <host_cpuid+0x34>
> 104b: 8b 55 d4 mov -0x2c(%ebp),%edx
> 104e: 89 02 mov %eax,(%edx)
> 1050: 8b 75 08 mov 0x8(%ebp),%esi
> 1053: 85 f6 test %esi,%esi
> 1055: 74 08 je 105f <host_cpuid+0x43>
> 1057: 8b 5d d0 mov -0x30(%ebp),%ebx
> 105a: 8b 4d 08 mov 0x8(%ebp),%ecx
> 105d: 89 19 mov %ebx,(%ecx)
> 105f: 8b 5d 0c mov 0xc(%ebp),%ebx
> 1062: 85 db test %ebx,%ebx
> 1064: 74 08 je 106e <host_cpuid+0x52>
> 1066: 8b 55 c4 mov -0x3c(%ebp),%edx
> 1069: 8b 45 0c mov 0xc(%ebp),%eax
> 106c: 89 10 mov %edx,(%eax)
> 106e: 8b 4d 10 mov 0x10(%ebp),%ecx
> 1071: 85 c9 test %ecx,%ecx
> 1073: 74 05 je 107a <host_cpuid+0x5e>
> 1075: 8b 4d 10 mov 0x10(%ebp),%ecx
> 1078: 89 39 mov %edi,(%ecx)
> 107a: 83 c4 3c add $0x3c,%esp
> 107d: 5b pop %ebx
> 107e: 5e pop %esi
> 107f: 5f pop %edi
> 1080: c9 leave
> 1081: c3 ret
>
>
> Looks like %ebx was chosen for %1. I also don't see where %eax is
> loaded.

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?

[-- Attachment #2: test.c --]
[-- Type: application/octet-stream, Size: 947 bytes --]

#include <stdio.h>

#define uint32_t unsigned int

static void host_cpuid(uint32_t function, uint32_t *eax, uint32_t *ebx,
uint32_t *ecx, uint32_t *edx)
{
uint32_t vec[4];

#if defined(__i386__) && defined(__PIC__)
asm volatile("movl %%ebx, %%esi \n\t"
"cpuid \n\t"
"movl %%ebx, %1 \n\t"
"movl %%esi, %%ebx"
: "=a" (vec[0]), "=r" (vec[1]), "=c" (vec[2]), "=d" (vec[3]) : "0"(function) : "esi", "cc");
#else
asm volatile("cpuid" : "=a" (vec[0]), "=b" (vec[1]),"=c" (vec[2]), "=d" (vec[3]) : "0"(function) : "cc");
#endif

if (eax)
*eax = vec[0];
if (ebx)
*ebx = vec[1];
if (ecx)
*ecx = vec[2];
if (edx)
*edx = vec[3];

}

int main(int argc, char **argv) {
unsigned int a,b,c,d;
host_cpuid(atoi(argv[1]), &a, &b, &c, &d);
printf("%#x = %#x %#x %#x %#x\n", atoi(argv[1]), a, b, c, d);
}

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]

[-- Attachment #4: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #5: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net