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

[Yu, Zhang]

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
>
>