Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem

[Lucas Stach <dev@lynxeye.de>]

Am Donnerstag, den 17.12.2020, 15:02 +0100 schrieb Christian König:
> Am 17.12.20 um 14:45 schrieb Robin Murphy:
> > On 2020-12-17 10:25, Christian König wrote:
> > > Am 17.12.20 um 02:07 schrieb Chen Li:
> > > > On Wed, 16 Dec 2020 22:19:11 +0800,
> > > > Christian König wrote:
> > > > > Am 16.12.20 um 14:48 schrieb Chen Li:
> > > > > > On Wed, 16 Dec 2020 15:59:37 +0800,
> > > > > > Christian König wrote:
> > > > > > > [SNIP]
> > > > > > Hi, Christian. I'm not sure why this change is a hack here. I 
> > > > > > cannot see the problem and wll be grateful if you give more 
> > > > > > explainations.
> > > > > __memset is supposed to work on those addresses, otherwise you 
> > > > > can't use the
> > > > > e8860 on your arm64 system.
> > > > If __memset is supposed to work on those adresses, why this 
> > > > commit(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2Fba0b2275a6781b2f3919d931d63329b5548f6d5f&data=04%7C01%7Cchristian.koenig%40amd.com%7C3551ae4972b044bb831608d8a291f81c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637438095114292394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xns81uCGfN1tjsVn5LBU8QhmUinZRJQlXz8w%2FJ7%2FGTM%3D&reserved=0) 
> > > > is needed? (I also notice drm/radeon didn't take this change though) 
> > > > just out of curiosity.
> > > 
> > > We generally accept those patches as cleanup in the kernel with the 
> > > hope that we can find a way to work around the userspace restrictions.
> > > 
> > > But when you also have this issue in userspace then there isn't much 
> > > we can do for you.
> > > 
> > > > > Replacing the the direct write in the kernel with calls to writel() or
> > > > > memset_io() will fix that temporary, but you have a more general 
> > > > > problem here.
> > > > I cannot see what's the more general problem here :( u mean 
> > > > performance?
> > > 
> > > No, not performance. See standards like OpenGL, Vulkan as well as 
> > > VA-API and VDPAU require that you can mmap() device memory and 
> > > execute memset/memcpy on the memory from userspace.
> > > 
> > > If your ARM base board can't do that for some then you can't use the 
> > > hardware with that board.
> > 
> > If the VRAM lives in a prefetchable PCI bar then on most sane 
> > Arm-based systems I believe it should be able to mmap() to userspace 
> > with the Normal memory type, where unaligned accesses and such are 
> > allowed, as opposed to the Device memory type intended for MMIO 
> > mappings, which has more restrictions but stricter ordering guarantees.
> 
> Do you have some background why some ARM boards fail with that?
> 
> We had a couple of reports that memset/memcpy fail in userspace (usually 
> system just spontaneously reboots or becomes unresponsive), but so far 
> nobody could tell us why that happens?

Optimized memset/memcpy uses unaligned access in some cases, where
handling unaligned start/end addresses would cause more instructions to
be used otherwise.

If the device memory isn't mapped at least writecombined (bufferable in
ARM speak) into userspace, those unaligned accesses are not allowed and
will cause traps on the hardware level. Normally this should just lead
to the process making the access getting killed with a SIGBUS, but
maybe some systems handle those traps wrong on a firmware level? If the
kernel makes such an unaligned access then the kernel will fault, which
normally means halting the kernel.

Regards,
Lucas


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel