<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 25.08.2011, at 07:31, Roedel, Joerg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:<br><blockquote type="cite">On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:<br></blockquote><font class="Apple-style-span" color="#540000"><br></font></div></blockquote><div><br></div><div>[...]</div><br><blockquote type="cite"><div><blockquote type="cite">We need to try the polite method of attempting to hot unplug the device<br></blockquote><blockquote type="cite">from qemu first, which the current vfio code already implements. We can<br></blockquote><blockquote type="cite">then escalate if it doesn't respond. The current code calls abort in<br></blockquote><blockquote type="cite">qemu if the guest doesn't respond, but I agree we should also be<br></blockquote><blockquote type="cite">enforcing this at the kernel interface. I think the problem with the<br></blockquote><blockquote type="cite">hard-unplug is that we don't have a good revoke mechanism for the mmio<br></blockquote><blockquote type="cite">mmaps.<br></blockquote><br>For mmio we could stop the guest and replace the mmio region with a<br>region that is filled with 0xff, no?<br></div></blockquote><div><br></div><div>Sure, but that happens in user space. The question is how does kernel space enforce an MMIO region to not be mapped after the hotplug event occured? Keep in mind that user space is pretty much untrusted here - it doesn't have to be QEMU. It could just as well be a generic user space driver. And that can just ignore hotplug events.</div><div><br></div><div><br></div><div>Alex</div></div><br></body></html>