[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] tools/xen-detect: avoid possible pitfall with cpuid()


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 3 Dec 2021 13:09:04 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EEAm6RV7+XIh6QsPEcjZTodJxZuPMJwRlxvbvSLKLZg=; b=QyRZMjbkOpclCTHyxwhyVL0O9RFSpfWZbkFHxIkW3nqdfNO3fk946iFXbNxNuS9Ib3YGSeC4SjAV/uWkWBFjt0qYxldwbZ5BWua55jP4jg0+AN4JednA0eQzuRBaxj6xxF4a0WXojipUR1dasVHBTaku/CH2i0+Uu+Ea+5bY/PI+UOsq0VunSAALZ8seQC+0+Te33oPPeGugFhXgYoQU8RE71MB+9yq0PiTWL286SV5rlOZrXdSQZg1mrCZYY/GZsZG4LZD/VsJrfvbh9qHGmkPcE/6pbEdTqsSjMxGGGG3eb23QZ28Cs2gSORLGhkswTsfWHRbebM98h6fz3xhU7w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XUSmjy3mo8kcJaKxpaLK5FFGUYK/OqtdjAS2TJxvBdA20u22M6hurjFzCYoJOaJhz8jpubtnM12K5JJdCJJKL1PkyuZJHLNewPoQ843ltvrVqWl4cR4rZqf3y60cJMAUm3kzBXlwl4imjSufnAYgmgEHXbxpis5YylrB7CjR3H8FMo7EGOeN5u2+G+52nGtKTWWW2//AxWM2O9VlNDN+BFHZnwDZADhkV9RkAgb3+rFnCr4FyKOyoi36EXh4waGNDKjq9t57xSZLSFT2pSapES48LM7bxblBHSO4FaZ/w+ruVsL/zzB1QYsOBNRcyhTj18R4lmtKAreNFrlSKMVcqQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 03 Dec 2021 12:09:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

The 64-bit form forces %ecx to 0 while the 32-bit one so far didn't - it
only ended up that way when "pv_context" is zero. While presently no
leaf queried by callers has separate subleaves, let's avoid chancing it.

While there
- replace references to operands by number,
- relax constraints where possible,
- limit PUSH/POP to just the registers not also used as input,
all where applicable also for the 64-bit variant.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
I'm pretty sure %edx also wouldn't need to be subject to PUSH/POP here,
but I didn't want to go more "against" the comment than obviously
justifiable by the input registers used. In fact I've observed gcc to
pick %edx for putting "pv_context" in.

--- a/tools/misc/xen-detect.c
+++ b/tools/misc/xen-detect.c
@@ -52,17 +52,19 @@ static void cpuid(uint32_t idx, uint32_t
 #ifdef __i386__
     /* Use the stack to avoid reg constraint failures with some gcc flags */
     asm volatile (
-        "push %%eax; push %%ebx; push %%ecx; push %%edx\n\t"
-        "test %1,%1 ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t"
-        "mov %%eax,(%2); mov %%ebx,4(%2)\n\t"
-        "mov %%ecx,8(%2); mov %%edx,12(%2)\n\t"
-        "pop %%edx; pop %%ecx; pop %%ebx; pop %%eax\n\t"
-        : : "a" (idx), "c" (pv_context), "S" (regs) : "memory" );
+        "push %%ebx; push %%edx\n\t"
+        "test %[pv],%[pv] ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t"
+        "mov %%eax,(%[regs]); mov %%ebx,4(%[regs])\n\t"
+        "mov %%ecx,8(%[regs]); mov %%edx,12(%[regs])\n\t"
+        "pop %%edx; pop %%ebx\n\t"
+        : "+a" (idx), "=c" (idx /* dummy */)
+        : "c" (0), [pv] "r" (pv_context), [regs] "SD" (regs)
+        : "memory" );
 #else
     asm volatile (
-        "test %5,%5 ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t"
+        "test %[pv],%[pv] ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t"
         : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3])
-        : "0" (idx), "1" (pv_context), "2" (0) );
+        : "0" (idx), "2" (0), [pv] "r" (pv_context) );
 #endif
 }
 




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.