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

[PATCH] x86: correct asm() constraints when dealing with immediate selector values

  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 9 Sep 2021 16:56:46 +0200
  • 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; bh=MQGjhvRmw+/DydvCB7DT+8K9D0V+T+CrHAAC2eFUce4=; b=OUMr46FNoLsuwW0uEstPr9F3E3Aj9DZ8hntFl6ULQB2W+8jqfvO+LSgqjFYsy/mtFfvq4Kl8N2AHrNAcpLrkDEHZdi3F1eAuIzgPb12nia8n4HXbTKjqKLjfYGAR96QznUXcKDUKw03ZCRnh+ICtZWzrKNmc9lSPIhS6J7vLrQFMKvE/PLsheVpdOeL0A6IueK14DP+irL0vG8HEr+N//d34lXvaKPwrebnur8Ealkan4GU3p4BOoQHNqniPnhgiXseYk4HYuYQsRNEeuI+3dRL1JUsY2P/DuUT9Byilc18ND94lheiQYl5Wwvq/5/lXi8R4Csy3VVV+zt6FoqJkZw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iVC/sKZRrV6eljHWC+2OsplFxjOmhizqj88M6VidgFCynh/t0CPQmMCJ+6JYnPqgboD3d7D1jHfEy+17Ss8/MJWt7IQ2xcCIDiX6hwMd/RiUBjLzR0rv/49XyT2JMSM0K+0WSVb87jB+22koKE2fo0iyiG61Sw1txZHpPtKrFDALU87DTCkIp8EhLFIQL1AsKayb+QcuV8CLcLEihgObh33CAJsJu9NjLKbbx07QgtTEixsGWoloRLy2Qx/Igkg4g1QxHvbpneZFQGGLDB1Krkqs3UKfdDVQPQTkDkDZOUM75wgwr0Qnp0zu6TZImig6TRXXXlWbpb6L7J1KEog4bA==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 09 Sep 2021 14:56:55 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

asm() constraints need to fit both the intended insn(s) which the
respective operands are going to be used with as well as the actual kind
of value specified. "m" (alone) together with a constant, however, leads
to gcc saying

error: memory input <N> is not directly addressable

while clang complains

error: invalid lvalue in asm input for constraint 'm'

And rightly so - in order to access a memory operand, an address needs
to be specified to the insn. In some cases it might be possible for a
compiler to synthesize a memory operand holding the requested constant,
but I think any solution there would have sharp edges.

If "m" alone doesn't work with constants, it is at best pointless (and
perhaps misleading or even risky - the compiler might decide to actually
pick "m" and not try very hard to find a suitable register) to specify
it alongside "r".

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -736,7 +736,7 @@ void __init detect_zen2_null_seg_behavio
        uint64_t base;
        wrmsrl(MSR_FS_BASE, 1);
-       asm volatile ( "mov %0, %%fs" :: "rm" (0) );
+       asm volatile ( "mov %0, %%fs" :: "r" (0) );
        rdmsrl(MSR_FS_BASE, base);
        if (base == 0)
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -248,7 +248,7 @@ void do_double_fault(struct cpu_user_reg
-    asm ( "lsll %1, %0" : "=r" (cpu) : "rm" (PER_CPU_SELECTOR) );
+    asm ( "lsll %1, %0" : "=r" (cpu) : "r" (PER_CPU_SELECTOR) );
     /* Find information saved during fault and dump it to the console. */
     printk("*** DOUBLE FAULT ***\n");



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