[root@carrizo ~]# xxd -l 1024 -s 0xC0000
/sys/kernel/debug/dri/0/amdgpu_iova
Actually 0xC0000 is a special address, e.g. video BIOS if I'm not
completely mistaken.
Take a look at /proc/iomem and try reading something which is marked as
"System RAM".
If that still works we are lost and need to get back to square one.
On the other hand give me a day to check if we can't figure out through
reverse mapping if a page is TTM allocated or not.
Christian.
Am 19.09.2017 um 19:37 schrieb Tom St Denis:
As I predicted ...
[root@carrizo ~]# xxd -l 1024 -s 0xC0000
/sys/kernel/debug/dri/0/amdgpu_iova
000c0000: 55aa 74e9 a902 0000 0000 0000 0000 0000 U.t.............
000c0010: 0000 0000 0000 0000 4c02 0000 0000 4942 ........L.....IB
000c0020: 4daa 2e93 0000 0000 0000 0000 0000 0004 M...............
000c0030: 2037 3631 3239 3535 3230 0000 0000 0000 761295520......
000c0040: a102 0000 0000 0000 2802 0000 0000 0000 ........(.......
000c0050: 3037 2f32 372f 3136 2030 343a 3036 0000 07/27/16 04:06..
000c0060: 3600 0000 e9b4 0300 e9c3 0300 0000 f400 6...............
000c0070: 0013 0000 00d0 0100 1a16 20e1 0280 7e00 .......... ...~.
000c0080: a200 4402 1200 0000 0000 003c 400e 0207 ..D........<@...
000c0090: 3c01 1a00 0400 0000 eea0 ff06 0008 3040 <.............0@
000c00a0: 0e01 0000 0000 0000 1403 0000 0000 0000 ................
000c00b0: be7e 1100 b907 1ad6 502c 0000 0000 0000 .~......P,......
000c00c0: 0000 0000 1440 4143 0000 0000 1000 0000 .....@AC........
000c00d0: 4200 0000 407c 0600 2000 2000 1200 0e00 B...@|.. . .....
000c00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000c00f0: 0000 0000 3131 332d 4339 3534 3031 3031 ....113-C9540101
000c0100: 2d30 3036 0046 474c 2045 4c4c 4553 4d45 -006.FGL ELLESME
000c0110: 5245 0050 4349 5f45 5850 5245 5353 0047 RE.PCI_EXPRESS.G
000c0120: 4444 5235 000d 0a43 3935 3420 506f 6c61 DDR5...C954 Pola
000c0130: 7269 7331 3020 474c 2041 3120 4744 4452 ris10 GL A1 GDDR
000c0140: 3520 3235 364d 7833 3220 3847 4220 3330 5 256Mx32 8GB 30
000c0150: 3065 2f33 3030 6d20 2020 2020 2020 2020 0e/300m
000c0160: 2020 2020 2020 2020 2020 2020 2020 2020
000c0170: 2020 200d 0a00 0d0a 200d 0a00 2843 2920 ..... ...(C)
000c0180: 3139 3838 2d32 3031 302c 2041 6476 616e 1988-2010, Advan
000c0190: 6365 6420 4d69 6372 6f20 4465 7669 6365 ced Micro Device
000c01a0: 732c 2049 6e63 2e00 4154 4f4d 4249 4f53 s, Inc..ATOMBIOS
000c01b0: 424b 2d41 4d44 2056 4552 3031 352e 3035 BK-AMD VER015.05
000c01c0: 302e 3030 302e 3030 302e 3030 3730 3036 0.000.000.007006
000c01d0: 0043 3935 3430 3130 312e 3030 3600 3132 .C9540101.006.12
000c01e0: 3935 3838 3720 0033 3534 3731 3220 2000 95887 .354712 .
000c01f0: 2020 2020 2020 2020 0041 4d44 5f45 4c4c .AMD_ELL
000c0200: 4553 4d45 5245 5f43 3935 3430 315f 5854 ESMERE_C95401_XT
000c0210: 5f41 315f 4744 355f 3847 425c 636f 6e66 _A1_GD5_8GB\conf
000c0220: 6967 2e68 0000 0090 2400 0101 4154 4f4d ig.h....$...ATOM
I can dump arbitrary system memory with the iommu enabled in the bios
via my carrizo "dev" in the debugfs entry.
So if the issue is arbitrary access is a no no (and I don't get why)
then the entire patch is a NAK because clearly I can "abuse" it.
Tom
On 19/09/17 01:26 PM, Tom St Denis wrote:
On 19/09/17 01:23 PM, Christian König wrote:
Am 19.09.2017 um 19:20 schrieb Tom St Denis:
On 19/09/17 01:18 PM, Christian König wrote:
Am 19.09.2017 um 19:14 schrieb Tom St Denis:
On 19/09/17 01:10 PM, Christian König wrote:
As far as I know we don't need #ifdefs cause there are dummy
functions when IOMMU is not compiled in.
But this patch is a NAK since it circumvents the /dev/mem
restriction when IOMMU is disabled and that is not something we
can easily allow.
I raised this objection 24 hours ago and was told to go ahead
with the read/write methods anyways.
Short of making a list of mappings/allocations in the ttm layer I
have no idea how we would track this in the non-iommu case which
means the entire iova debugfs entry should have been NAK'ed in
the first place.
I'm open to suggestions.
As long as IOMMU is enabled the entry is perfectly fine, cause
only memory mapped to the IOMMU is accessible to the GPU and so
accessible using the debugfs entry as well.
On devices where there's no translation (e.g. Carrizo) does the
iommu layer track mappings? I'm wondering if on those I could seek
outside of boundaries and read system memory anyways.
Why do you think there isn't any translation on CZ? I mean the whole
ATC thing uses the IOMMU (v2 in this case) on APUs.
On my Carrizo devel system (A12-9800) the GPU dma addresses are
physical addresses. I only first saw iommu with APUs enabled on Raven.
I'll see if I can read non-mapped pages via the iova file on my Carrizo.
Only when IOMMU is disabled we can't go this way cause we can't
know which memory is mapped to the driver and which isn't (or
could we somehow track this?).
I suggest to not create the file in the first place if IOMMU is
disabled.
I could easily do this (basically check if the domain is not null
at debugfs init time).
Yeah, please do this for now.
I mean it would be great to have this interface even with IOMMU
disabled, but of hand I can't think of a way to allow this.
Sent to the list already. Tested with enabled/disabled. Seems to
work for me.
Tom
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
