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

Tvrtko Ursulin
2014-12-16T15:24:56Z

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