On Fri, Mar 31, 2023 at 09:33:31AM -0500, Tom Lendacky wrote:
On 3/31/23 09:09, Kirill A. Shutemov wrote:
On Fri, Mar 31, 2023 at 08:40:30AM -0500, Tom Lendacky wrote:
On 3/31/23 05:06, Kirill A. Shutemov wrote:
On Fri, Mar 31, 2023 at 08:49:48AM +0000, David Laight wrote:
From: Wu Zongyong
Sent: 31 March 2023 03:24
On Thu, Mar 30, 2023 at 03:39:51PM +0300, kirill.shutemov@xxxxxxxxxxxxxxx wrote:
On Wed, Mar 29, 2023 at 10:59:37AM +0800, Wu Zongyong wrote:To be honest, I don't find a specific user which uses the MOVSXD.
It seems MOVSXD which opcode is 0x63 is not handled, support
to decode it in insn_decode_mmio().
Do you have a particular user in mind?
But both Intel and AMD's instructions reference contains MOVSXD and lots
of MOVSXD instructions occur when I "objdump -S vmlinux", so I think it
may be useful to support it in insn_decode_mmio().
Are there some special consideration about this instruction?
It is a sign-extending memory read (32bit to 64bit).
You pretty much never want to do that to a device register.
Also kernel code should be using readl() (etc) which do
unsigned reads.
So they should never happen for mmio.
Of course, if you mmap() PCIe space directly into a program's
address space anything might happen ...
There are two users of the interface: TDX and SEV. TDX doesn't allow
userspace MMIO. SEV *seems* allows it, but I am not sure how it is safe.
Tom?
The insn_decode_mmio() function is only called by the SEV/TDX related code
and is specifically MMIO oriented. As David said, this instruction is likely
not being used for that in the kernel. If we come across a case where this
is used, we can look at how it is being used in that situation and it can be
addressed then.
I was asking if SEV supports userspace MMIO. And if yes, how do you make
it safe?
No, SEV doesn't support userspace MMIO.
But where do you filter out userspace MMIO? AFAICS, it goes straight from
from #VC to insn_decode_mmio(). Hm?