Re: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Jan 24, 2024 at 09:29:24PM -0400, Jason Gunthorpe wrote:
> On Wed, Jan 24, 2024 at 05:54:49PM +0000, Catalin Marinas wrote:
> > On Wed, Jan 24, 2024 at 11:52:25AM -0400, Jason Gunthorpe wrote:
> > > 2) Userspace does ST4 to MMIO memory, and the VMM can't explode
> > >    because of this. Replacing the ST4 with 8x STR is NOT better,
> > >    that would be a big performance downside, especially for the
> > >    quirky hi-silicon hardware.
> > 
> > I was hoping KVM injects an error into the guest rather than killing it
> > but at a quick look I couldn't find it. The kvm_handle_guest_abort() ->
> > io_mem_abort() ends up returning -ENOSYS while handle_trap_exceptions()
> > only understands handled or not (like 1 or 0). Well, maybe I didn't look
> > deep enough.
> 
> It looks to me like qemu turns on the KVM_CAP_ARM_NISV_TO_USER and
> then when it gets a NISV it always converts it to a data abort to the
> guest. See kvm_arm_handle_dabt_nisv() in qemu. So it is just a
> correctness issue, not a 'VM userspace can crash the VMM' security
> problem.

The VMM wasn't my concern but rather a guest getting killed or not
functioning correctly (user app killed).

> Thus, IMHO, doing IO emulation for VFIO that doesn't support all the
> instructions actual existing SW uses to do IO is hard to justify. We
> are already on a slow path that only exists for technical correctness,
> it should be perfect. It is perfect on x86 because x86 KVM does SW
> instruction decode and emulation. ARM could too, but doesn't.

It could fall back to instruction decode, either in KVM or the VMM
(strong preference for the latter), but I'd only do this if it's
justified.

I don't think the issue here is VFIO, I doubt we'd ever see emulation
for hardware like mlx5. But we are changing generic kernel functions
like memcpy_toio/__iowrite64_copy() that end up being used in other
drivers (e.g. USB, UART) for emulated devices. If we can keep these
functions as generic as possible for both guest and native runs, that's
great. If the performance difference is significant, we can revisit.

-- 
Catalin