Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp350792pxk; Thu, 24 Sep 2020 07:10:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzHYyVHTPVp9klVzQB0eB2oKqHeojC4v8RPDEICMDJ5/wkY2pR1DfOb76/U+Wub2fdei9D2 X-Received: by 2002:a17:906:a4b:: with SMTP id x11mr93447ejf.368.1600956638817; Thu, 24 Sep 2020 07:10:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600956638; cv=none; d=google.com; s=arc-20160816; b=iNNX1WBp/RSud64in/T7INqT2/ZbCcwO+IpcNWQa8yOVTGpAHaRVy8fjsdmaqVILrY Po5IurXEte7QUzZfxe06ivMJWTs4ryLKP9rxf57uA9CCDoTZbGEKM0NQH0DZBIE/rKnh WskFmcaGsEuH7CMPg0Dd+jWQWf1JQRh76nlzRbPOdjn/qKL0wrlffU1Lzggy37gaHFy/ jE2wPdDB54VaRVVepUB10qQAIGoFF6B+e0Ibol7QQg6CYw9tsA+o9M/5ldunjOErRlLo AewPNi9pyEj3omgMkfUfqANuEJN/Uw4bDNdLhOs9Q6Qtn9pNPg3Un9z64ouN53/M7nOu vUiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=wPA+QSggzL2XjvmjpCJvIIRwRWL7jqAyTMISVDGYuiU=; b=OyCZYvjrvSW4Pro2KUvqqn3Cnj7RZCabLx1I0cJViqTZg81IXDBDV6fLsWzp9rwWNm oldYD5+9iTNzTpg42WRb8c1ciUXhjnwn4ESEnJQrwxZJmf/ekqhgsjn0Hgnsz1MX7Veb sGb0tizIDmqQTU4/qORA+61xmDuiBjtOXOjkb8u5/LMsiUmVOMhQiLv6m4KoWgDeab+g LOKiu+ZAxm+htDuwrZ8vxGzWhMIf6DE/GWLFnEE5pliH9vNZiaUnJyfs8sim2BotAN4m pW0plCi2HpmbXnqYA7kCyuRLHZFEBQmCkVnTYl7me13qv8jtFTt79BIcQGiac02g5sxe KLQQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay26si2136069edb.269.2020.09.24.07.10.09; Thu, 24 Sep 2020 07:10:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728182AbgIXOHg (ORCPT + 99 others); Thu, 24 Sep 2020 10:07:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:51304 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728101AbgIXOH1 (ORCPT ); Thu, 24 Sep 2020 10:07:27 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5DD09AB0E; Thu, 24 Sep 2020 14:07:25 +0000 (UTC) Date: Thu, 24 Sep 2020 14:07:25 +0000 (UTC) From: Michael Matz To: Borislav Petkov cc: David Laight , 'Dave Jiang' , "vkoul@kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "dan.j.williams@intel.com" , "tony.luck@intel.com" , "jing.lin@intel.com" , "ashok.raj@intel.com" , "sanjay.k.kumar@intel.com" , "fenghua.yu@intel.com" , "kevin.tian@intel.com" , "dmaengine@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v5 1/5] x86/asm: Carve out a generic movdir64b() helper for general usage In-Reply-To: <20200924101506.GD5030@zn.tnic> Message-ID: References: <160090233730.44288.4446779116422752486.stgit@djiang5-desk3.ch.intel.com> <160090264332.44288.7575027054245105525.stgit@djiang5-desk3.ch.intel.com> <20200924101506.GD5030@zn.tnic> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, even though we hashed it out downthread, let me make some additional remarks: On Thu, 24 Sep 2020, Borislav Petkov wrote: > > /* MOVDIR64B [rdx], rax */ This comment is confusing as it uses Intel syntax for the operand forms, but AT&T order (dest last). > volatile struct { char _[64]; } *__dst = dst; > > ... > > : "=m" (__dst) This and the other occurences in this thread up to now always miss that the 'm' constraints want the object itself, not the address of the object. So you want '"m" (*__src)', same for dst, and so on. > Micha, the instruction is: > > MOVDIR64B %(rdx), rax > > "Move 64-bytes as direct-store with guaranteed 64-byte write atomicity > from the source memory operand address to destination memory address > specified as offset to ES segment in the register operand." It's unfortunate that the introduction of this mnemonic into binutils did it wrong already, but what the instruction should really read like in AT&T mode is: movdir64b (%rdx), (%rax) or even movdir64b (%rdx), es:(%rax) because both are memory operands really (even though the destination can only be encoded with a direct register, as these are the constraints of x86 insn encodings). It's comparable to movs, which, also having two memory operands is written: movsb %ds:(%rsi),%es:(%rdi) Ciao, Michael.