Hi Cong,
when I understand Robin correctly all mapping (host, guest, kernel,
userspace etc..) must have the same caching attributes unless you use
the S2FWB feature introduced with Armv8.4.
If you don't follow those rules you usually run into coherency issues or
even worse system hangs. So you not only need to adjust the kernel
mappings, but also the function for userspace mappings to follow those
rules.
Additional to that I think I read Robin correctly that mapping the
resource write combined should be sufficient to solve your problem. So I
suggest to use that instead.
On the other hand if you manage to fix this completely for arm64 by
updating all the places to use cached mappings I'm fine with it as well.
It's then up to Dave to decide if that's something we want because QXL
is intentionally emulating a hardware device as far as I know.
Regards,
Christian.
Am 24.03.22 um 08:04 schrieb liuco...@kylinos.cn:
Hi Christian,
Can you help explain more detail under what circumstances userspace
mapping
will be problematic, you mean cached mappings also need adjustment in
function ttm_prot_from_caching?
Regards,
Cong.
*主 题：*Re: 回复: Re: 回复: Re: [PATCH v1 1/2] drm/qxl: replace ioremap
by ioremap_cache on arm64
*日 期：*2022-03-23 18:17
*发件人：*Christian König
*收件人：*liucong2@kylinos.cnairlied@redhat.comkraxel@redhat.comairlied@linux.iedaniel@ffwll.chray.huang@amd.comvirtualization@lists.linux-foundation.orgspice-devel@lists.freedesktop.orgdri-de...@lists.freedesktop.org
Hi Cong,
yes I've seen that, but that is still not sufficient.
You need to update the check in ttm_module.c as well or otherwise
your userspace mapping might not work correctly either.
Regards,
Christian.
Am 23.03.22 um 11:00 schrieb liuco...@kylinos.cn:
Hi Christian,
another commit fix the case in ttm. I send two patches at the
same time, but seems I miss
'--cover-letter' when run format-patch or some other bad
operation.
Regards,
Cong.
*主 题：*Re: 回复: Re: [PATCH v1 1/2] drm/qxl: replace
ioremap by ioremap_cache on arm64
*日 期：*2022-03-23 17:34
*发件人：*Christian König
*收件人：*liucong2@kylinos.cnairlied@redhat.comkraxel@redhat.comairlied@linux.iedaniel@ffwll.chray.huang@amd.comvirtualization@lists.linux-foundation.orgspice-devel@lists.freedesktop.orgdri-de...@lists.freedesktop.org
Hi Cong,
well than Dave must decide what to do here.
When QXL emulates a device it should also not use
memory accesses which won't work on a physical device.
BTW: Your patch is really buggy, it misses the cases
in ttm_module.c
Regards,
Christian.
Am 23.03.22 um 09:48 schrieb liuco...@kylinos.cn:
Hi Christian,
according to 'Arm Architecture Reference Manual
Armv8,for Armv8-A
architecture profile' pdf E2.6.5
E2.6.5 Generation of Alignment faults by load/store
multiple accesses to
Device memory
When FEAT_LSMAOC is implemented and the value of
the applicable nTLSMD
field is 0, any memory access by an AArch32 Load
Multiple or Store
Multiple instruction to an address that the
stage 1 translation
assigns as Device-nGRE, Device-nGnRE, or
Device-nGnRnE generates
an Alignment fault.
so it seems not just some ARM boards doesn't allow
unaligned access to MMIO
space, all pci memory mapped as Device-nGnRE in arm64 cannot
support
unaligned access. and qxl is a device simulated by
qemu, it should be able to access
to MMIO space in a more flexible way(PROT_NORMAL)
than the real physical
graphics card.
Cong.
*主 题：*Re: [PATCH v1 1/2] drm/qxl: replace
ioremap by ioremap_cache on arm64
*日 期：*2022-03-23 15:15
*发件人：*Christian König
*收件人：*CongLiuairlied@redhat.comkraxel@redhat.comairlied@linux.iedaniel@ffwll.chray.huang@amd.comvirtualization@lists.linux-foundation.orgspice-devel@lists.freedesktop.orgdri-de...@lists.freedesktop.org
Am 22.03.22 um 10:34 schrieb Cong Liu:
> qxl use ioremap to map ram_header and rom,
in the arm64 implementation,
> the device is mapped as DEVICE_nGnRE, it
can not support unaligned
> access.
Well that some ARM boards doesn't allow
unaligned access to MMIO space
is a well known bug of those ARM boards.
So as far as I know this is a hardware bug
you are trying to workaround
here and I'm not 100% sure that this is
correct.
Christian.
>
>
