[Intel-gfx] [PATCH v3 2/8] drm/i915: Adds graphic address space ballooning logic

[Tvrtko Ursulin]

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. :)

Regards,

Tvrtko