<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">Am 08.02.21 um 23:09 schrieb Andrey
Grodzovsky:<br>
</div>
<blockquote type="cite"
cite="mid:3f7efc21-f2fb-73a9-216c-aa1e531e35a0@amd.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 2/8/21 4:37 AM, Christian König
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fcb2cf17-d011-55c6-1545-9fa190e358c3@gmail.com">Am
07.02.21 um 22:50 schrieb Daniel Vetter: <br>
<blockquote type="cite">[SNIP] <br>
<blockquote type="cite">Clarification - as far as I know there
are no page fault handlers for kernel <br>
mappings. And we are talking about kernel mappings here,
right ? If there were <br>
I could solve all those issues the same as I do for user
mappings, by <br>
invalidating all existing mappings in the kernel (both kmaps
and ioreamps)and <br>
insert dummy zero or ~0 filled page instead. <br>
Also, I assume forcefully remapping the IO BAR to ~0 filled
page would involve <br>
ioremap API and it's not something that I think can be
easily done according to <br>
am answer i got to a related topic a few weeks ago <br>
<a class="moz-txt-link-freetext"
href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Flinux-pci%2Fmsg103396.html&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Cb159d3ce264944486c8008d8cc15233a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637483738446813868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6eP0nhS%2BZwp1Y54CwfX8vaV3FTWbW8IylW5JFaf92pY%3D&reserved=0"
moz-do-not-send="true">https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Flinux-pci%2Fmsg103396.html&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Cb159d3ce264944486c8008d8cc15233a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637483738446813868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6eP0nhS%2BZwp1Y54CwfX8vaV3FTWbW8IylW5JFaf92pY%3D&reserved=0</a>
(that was the only reply <br>
i got) <br>
</blockquote>
mmiotrace can, but only for debug, and only on x86 platforms:
<br>
<br>
<a class="moz-txt-link-freetext"
href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fdoc%2Fhtml%2Flatest%2Ftrace%2Fmmiotrace.html&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Cb159d3ce264944486c8008d8cc15233a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637483738446813868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QBF9J%2BVIRUkUTTjvNoZR8NqFNt8CpHkcknH2qKX7dd8%3D&reserved=0"
moz-do-not-send="true">https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fdoc%2Fhtml%2Flatest%2Ftrace%2Fmmiotrace.html&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Cb159d3ce264944486c8008d8cc15233a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637483738446813868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QBF9J%2BVIRUkUTTjvNoZR8NqFNt8CpHkcknH2qKX7dd8%3D&reserved=0</a>
<br>
<br>
Should be feasible (but maybe not worth the effort) to extend
this to <br>
support fake unplug. <br>
</blockquote>
<br>
Mhm, interesting idea you guys brought up here. <br>
<br>
We don't need a page fault for this to work, all we need to do
is to insert dummy PTEs into the kernels page table at the place
where previously the MMIO mapping has been. <br>
</blockquote>
<p><br>
</p>
<p>But that exactly what Mathew from linux-mm says is not a
trivial thing to do, quote:</p>
<p>"</p>
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">ioremap() is done through the vmalloc space. It would, in theory, be
possible to reprogram the page tables used for vmalloc to point to your
magic page. I don't think we have such a mechanism today, and there are
lots of problems with things like TLB flushes. It's probably going to
be harder than you think.
"</pre>
</blockquote>
<br>
I haven't followed the full discussion, but I don't see much
preventing this.<br>
<br>
All you need is a new ioremap_dummy() function which takes the old
start and length of the mapping.<br>
<br>
Still a bit core and maybe even platform code, but rather useful I
think.<br>
<br>
Christian.<br>
<br>
<blockquote type="cite"
cite="mid:3f7efc21-f2fb-73a9-216c-aa1e531e35a0@amd.com">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">
If you believe it's actually doable then it would be useful not only for simulating device
unplugged situation with all MMIOs returning 0xff... but for actual handling of driver accesses
to MMIO after device is gone and, we could then drop entirely this patch as there would be no need
to guard against such accesses post device unplug.</pre>
</blockquote>
<br>
<br>
<blockquote type="cite"
cite="mid:3f7efc21-f2fb-73a9-216c-aa1e531e35a0@amd.com">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">
</pre>
<blockquote type="cite"
cite="mid:fcb2cf17-d011-55c6-1545-9fa190e358c3@gmail.com"> <br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">But ugh ... <br>
<br>
Otoh validating an entire driver like amdgpu without such
a trick <br>
against 0xff reads is practically impossible. So maybe you
need to add <br>
this as one of the tasks here? <br>
</blockquote>
Or I could just for validation purposes return ~0 from all
reg reads in the code <br>
and ignore writes if drm_dev_unplugged, this could already
easily validate a big <br>
portion of the code flow under such scenario. <br>
</blockquote>
Hm yeah if your really wrap them all, that should work too.
Since <br>
iommappings have __iomem pointer type, as long as amdgpu is
sparse <br>
warning free, should be doable to guarantee this. <br>
</blockquote>
<br>
Problem is that ~0 is not always a valid register value. <br>
<br>
You would need to audit every register read that it doesn't use
the returned value blindly as index or similar. That is quite a
bit of work. <br>
</blockquote>
<p><br>
</p>
<p>But ~0 is the value that will be returned for every read post
device unplug, regardless if it's valid or not, and we have to
cope with<br>
it then, no ?</p>
<p>Andrey</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:fcb2cf17-d011-55c6-1545-9fa190e358c3@gmail.com"> <br>
Regards, <br>
Christian. <br>
<br>
<blockquote type="cite">-Daniel <br>
<br>
<blockquote type="cite">Andrey <br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
amd-gfx mailing list
<a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a>
</pre>
</blockquote>
<br>
</body>
</html>