From: Borislav Petkov <bp@alien8.de>
To: David Laight <David.Laight@ACULAB.COM>, Michael Matz <matz@suse.de>
Cc: 'Dave Jiang' <dave.jiang@intel.com>,
"vkoul@kernel.org" <vkoul@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"jing.lin@intel.com" <jing.lin@intel.com>,
"ashok.raj@intel.com" <ashok.raj@intel.com>,
"sanjay.k.kumar@intel.com" <sanjay.k.kumar@intel.com>,
"fenghua.yu@intel.com" <fenghua.yu@intel.com>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
"linux-kernel@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
Date: Thu, 24 Sep 2020 12:15:06 +0200 [thread overview]
Message-ID: <20200924101506.GD5030@zn.tnic> (raw)
In-Reply-To: <a8c81da06df2471296b663d40b186c92@AcuMS.aculab.com>
On Thu, Sep 24, 2020 at 08:24:46AM +0000, David Laight wrote:
> static inline void movdir64b(void *dst, const void *src)
> {
> /*
> * 64 bytes from dst are marked as modified for completeness.
> * Since the writes bypass the cache later reads may return
> * old data anyway.
> */
> /* MOVDIR64B [rdx], rax */
> asm volatile (".byte 0x66, 0x0f, 0x38, 0xf8, 0x02"
> : "=m" ((struct { char _[64];} *)dst),
> : "m" ((struct { char _[64];} *)src), "d" (src), "a" (dst));
Now since you're so generous with your advice on random threads, please
explain what you're advising here?
The destination operand - in this case in %rax - is "destination memory
address specified as offset to ES segment in the register operand."
So what is the difference between:
...(void *dst, ... )
volatile struct { char _[64]; } *__dst = dst;
...
: "=m" (__dst)
: "a" (__dst)
and
...(void *dst, ... )
...
: "=m" ((struct { char _[64];} *)dst)
: "a" (__dst)
and why?
Point me to the gcc documentation where this is explained.
To cut to the chase, I don't think you need to do that, otherwise clwb()
would be broken too but perhaps you know something I don't.
Looking at clwb(), I believe the proper specification should be:
volatile struct { char _[64]; } *__dst = dst;
...
: "+m" (__dst)
: "a" (__dst)
And if anything, the source specification should be something like that:
volatile struct { char x[64]; } *__src = src;
...
"d" (__src)
because this tells gcc that the source operand would read 64 bytes
through the pointer in the %rdx reg.
So this ends up close to what you're saying but it is using local
variables to make the asm actually readable.
Lemme add Micha to Cc for sanity-checking:
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."
Do I need to tell gcc that both operands are referencing 64 bytes,
source operand is a memory reference, destination operand is an address
specified in a register?
What we have currently is:
volatile struct { char _[64]; } *dst = __dst;
/* MOVDIR64B [rdx], rax */
asm volatile(".byte 0x66, 0x0f, 0x38, 0xf8, 0x02"
: "=m" (dst)
: "d" (from), "a" (dst));
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2020-09-24 10:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <160090233730.44288.4446779116422752486.stgit@djiang5-desk3.ch.intel.com>
2020-09-23 23:10 ` [PATCH v5 3/5] dmaengine: idxd: Add shared workqueue support Dave Jiang
2020-09-23 23:11 ` [PATCH v5 4/5] dmaengine: idxd: Clean up descriptors with fault error Dave Jiang
2020-09-23 23:11 ` [PATCH v5 5/5] dmaengine: idxd: Add ABI documentation for shared wq Dave Jiang
[not found] ` <160090264332.44288.7575027054245105525.stgit@djiang5-desk3.ch.intel.com>
2020-09-24 8:24 ` [PATCH v5 1/5] x86/asm: Carve out a generic movdir64b() helper for general usage David Laight
2020-09-24 10:15 ` Borislav Petkov [this message]
2020-09-24 10:42 ` David Laight
2020-09-24 11:02 ` Borislav Petkov
2020-09-24 11:25 ` David Laight
2020-09-24 14:07 ` Michael Matz
2020-09-24 13:07 ` Borislav Petkov
2020-09-24 13:27 ` David Laight
2020-09-24 15:07 ` Dave Jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200924101506.GD5030@zn.tnic \
--to=bp@alien8.de \
--cc=David.Laight@ACULAB.COM \
--cc=ashok.raj@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=fenghua.yu@intel.com \
--cc=jing.lin@intel.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matz@suse.de \
--cc=mingo@redhat.com \
--cc=sanjay.k.kumar@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.