From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"Kumar, Sanjay K" <sanjay.k.kumar@intel.com>,
jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH] iommu/vt-d: Handle volatile descriptor status read
Date: Mon, 17 Jun 2024 14:05:10 -0700 [thread overview]
Message-ID: <20240617140510.3a405344@jacob-builder> (raw)
In-Reply-To: <BN9PR11MB52765C0508922F9CDEAE7E9D8CCD2@BN9PR11MB5276.namprd11.prod.outlook.com>
On Mon, 17 Jun 2024 03:04:36 +0000, "Tian, Kevin" <kevin.tian@intel.com>
wrote:
> > From: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > Sent: Saturday, June 8, 2024 1:38 AM
> >
> > Queued invalidation wait descriptor status is volatile in that IOMMU
> > hardware
> > writes the data upon completion.
> >
> > Use READ_ONCE() to prevent compiler optimizations which ensures memory
> > reads every time. As a side effect, READ_ONCE() also enforces strict
> > types and
> > may add an extra instruction. But it should not have negative
> > performance impact since we use cpu_relax anyway and the extra time(by
> > adding an instruction) may allow IOMMU HW request cacheline ownership
> > easier.
>
> I didn't get the meaning of the last sentence.
The wait descriptor is polled by the CPU and written by the IOMMU
concurrently. The IOMMU needs to have the cacheline ownership before
writing the status data to signal completion of the wait descriptor.
If the CPU polling loop is very tight, it might make IOMMU request for
ownership contentious/difficult. Since we already use pause (cpu_relax())
to ease the contention, adding an additional instruction
mov (%rax),%eax
Will make the cacheline even less contentious since it is just register mov,
no memory access.
> >
> > e.g. gcc 12.3
> > BEFORE:
> > 81 38 ad de 00 00 cmpl $0x2,(%rax)
> >
> > AFTER (with READ_ONCE())
> > 772f: 8b 00 mov (%rax),%eax
> > 7731: 3d ad de 00 00 cmp $0x2,%eax //status data
> > is 32 bit
> >
> > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
>
> Do we need a fix tag here?
I cannot find the exact commit, this is really old code.
> otherwise looks good to me:
>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Thanks,
Jacob
next prev parent reply other threads:[~2024-06-17 21:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 17:38 [PATCH] iommu/vt-d: Handle volatile descriptor status read Jacob Pan
2024-06-17 3:04 ` Tian, Kevin
2024-06-17 21:05 ` Jacob Pan [this message]
2024-06-18 2:54 ` Yi Liu
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=20240617140510.3a405344@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sanjay.k.kumar@intel.com \
--cc=yi.l.liu@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox