From: kirill.shutemov@linux.intel.com
To: Kai Huang <kai.huang@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
dave.hansen@intel.com, tglx@linutronix.de, bp@alien8.de,
mingo@redhat.com, peterz@infradead.org, rafael@kernel.org,
dan.j.williams@intel.com, hpa@zytor.com, geert@linux-m68k.org,
bhe@redhat.com, akpm@linux-foundation.org, rppt@kernel.org,
frederic@kernel.org, dave.jiang@intel.com, xin3.li@intel.com,
rick.p.edgecombe@intel.com, isaku.yamahata@intel.com,
yuan.yao@intel.com
Subject: Re: [PATCH] x86/asm: Remove the __iomem annotation of movdir64b()'s dst argument
Date: Fri, 5 Jan 2024 02:52:01 +0300 [thread overview]
Message-ID: <20240104235201.hzv2kb7vxocs3asx@box> (raw)
In-Reply-To: <20240104221219.572258-1-kai.huang@intel.com>
On Fri, Jan 05, 2024 at 11:12:19AM +1300, Kai Huang wrote:
> Commit e56d28df2f66 ("x86/virt/tdx: Configure global KeyID on all
> packages") causes below sparse check warning:
>
> arch/x86/virt/vmx/tdx/tdx.c:683:27: warning: incorrect type in argument 1 (different address spaces)
> arch/x86/virt/vmx/tdx/tdx.c:683:27: expected void [noderef] __iomem *dst
> arch/x86/virt/vmx/tdx/tdx.c:683:27: got void *
>
> The reason is TDX must use the MOVDIR64B instruction to convert TDX
> private memory (which is normal RAM but not MMIO) back to normal. The
> TDX code uses existing movdir64b() helper to do that, but the first
> argument @dst of movdir64b() is annotated with __iomem.
>
> When movdir64b() was firstly introduced in commit 0888e1030d3e
> ("x86/asm: Carve out a generic movdir64b() helper for general usage"),
> it didn't have the __iomem annotation. But this commit also introduced
> the same "incorrect type" sparse warning because the iosubmit_cmds512(),
> which was the solo caller of movdir64b(), has the __iomem annotation.
>
> This was later fixed by commit 6ae58d871319 ("x86/asm: Annotate
> movdir64b()'s dst argument with __iomem"). That fix was reasonable
> because until TDX code the movdir64b() was only used to move data to
> MMIO location, as described by the commit message:
>
> ... The current usages send a 64-bytes command descriptor to an MMIO
> location (portal) on a device for consumption. When future usages for
> the MOVDIR64B instruction warrant a separate variant of a memory to
> memory operation, the argument annotation can be revisited.
>
> Now TDX code uses MOVDIR64B to move data to normal memory so it's time
> to revisit.
>
> The SDM says the destination of MOVDIR64B is "memory location specified
> in a general register", thus it's more reasonable that movdir64b() does
> not have the __iomem annotation on the @dst.
>
> Remove the __iomem annotation from the @dst argument of movdir64b() to
> fix the sparse warning in TDX code. Similar to memset_io(), introduce a
> new movdir64b_io() to cover the case where the destination is an MMIO
> location, and change the solo caller iosubmit_cmds512() to use the new
> movdir64b_io().
>
> In movdir64b_io() explicitly use __force in the type casting otherwise
> there will be below sparse warning:
>
> warning: cast removes address space '__iomem' of expression
>
> Fixes: e56d28df2f66 ("x86/virt/tdx: Configure global KeyID on all packages")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312311924.tGjsBIQD-lkp@intel.com/
> Signed-off-by: Kai Huang <kai.huang@intel.com>
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2024-01-04 23:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 22:12 Kai Huang
2024-01-04 23:04 ` Dave Jiang
2024-01-04 23:52 ` kirill.shutemov [this message]
2024-01-05 2:35 ` Yuan Yao
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=20240104235201.hzv2kb7vxocs3asx@box \
--to=kirill.shutemov@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.jiang@intel.com \
--cc=frederic@kernel.org \
--cc=geert@linux-m68k.org \
--cc=hpa@zytor.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xin3.li@intel.com \
--cc=yuan.yao@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
all inboxes | Powered by JetHome®