On 12/16/2014 11:15 PM, Tvrtko Ursulin wrote:
Hi,
On 12/16/2014 02:39 PM, Gerd Hoffmann wrote:
Out of curiosity, what will be the mechanism to prevent a vGPU
instance
from ignoring the ballooning data? Must be something in the hypervisor
blocking pass-through access to such domains?
Well, although we have range check logic in the host side(which checks
the legality of a GM address), the correctness of a GM from vGPU side
Oh, I thought that part is direct for performance reasons (avoiding
translation). It's not then?
are supposed to be guaranteed by the drm mm allocator - all those
ballooned out spaces are marked as reserved.
I was thinking about a malicious i915 driver instance, or simply a bug
in DRM or i915 which breaks the blocked ranges assumption.
Cover letter had a link to a longish paper explaining how all this works
in detail.
Short summary:
* Direct access is denied by simply mapping only the guests piece
of memory into the guest address space.
* Indirect access (via exec buffer commands) is denied by verifying
the exec buffer commands (map read-only + verify + hand over to
the hardware when checks pass).
* The ballooning basically makes the guest aware what the offset for
its piece of memory has, so the references in the execbuffer don't
need to be translated, only verified.
Thanks, I did read the blog and powerpoint from the link, but didn't
find what you wrote below even after the second read. Probably missed
due to lack of domain knowledge.
Anyway, I just wanted to hear that the DRM allocation range is not the
only thing preventing access outside the allocated range. :)
Thanks, Tvrtko & Gerd.
DRM allocation range is not the only guarantee. We also have range check
functions in our host code. MMIO accesses and ring buffer commands will
be checked/scanned in the host side to see if there's any illegal GM
address.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
