On Wed, Jan 17, 2024 at 08:36:18AM -0400, Jason Gunthorpe wrote: > On Wed, Jan 17, 2024 at 12:30:00PM +0000, Mark Rutland wrote: > > On Tue, Jan 16, 2024 at 02:51:21PM -0400, Jason Gunthorpe wrote: > > > Hey Catalin, > > > > > > I'm just revising this and I'm wondering if you know why ARM64 has this: > > > > > > #define __raw_writeq __raw_writeq > > > static __always_inline void __raw_writeq(u64 val, volatile void __iomem *addr) > > > { > > > asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr)); > > > } > > > > > > Instead of > > > > > > #define __raw_writeq __raw_writeq > > > static __always_inline void __raw_writeq(u64 val, volatile void __iomem *addr) > > > { > > > asm volatile("str %x0, %1" : : "rZ" (val), "m" (*(volatile u64 *)addr)); > > > } > > > > > > ?? Like x86 has. > > > > I believe this is for the same reason as doing so in all of our other IO > > accessors. > > > > We've deliberately ensured that our IO accessors use a single base register > > with no offset as this is the only form that HW can represent in ESR_ELx.ISS.SRT > > when reporting a stage-2 abort, which a hypervisor may use for > > emulating IO. > > Wow, harming bare metal performace to accommodate imperfect emulation > sounds like a horrible reason :( > > So what happens with this patch where IO is done with STP? Are you > going to tell me I can't do it because of this? I should also point out that userspace IO doesn't follow such a restriction since nobody ever knew, and things like RDMA stack and DPDK use ST4 and probably other non-trivial instructions for IO from userspace. I'm fearful you saying today's hypervisors don't work right on ARM if IO is trapped, which does happen for some legimiate reasons and a few illegitimate ones?? Jason