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

[Tian, Kevin]

> From: Yu, Zhang
> Sent: Wednesday, December 17, 2014 11:10 AM
> > 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?

yes, just for performance reason to avoid translation

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

host will validate all the addresses submitted by the guest, w/ the assumption
that ballooning is in place so if the address is outside of the allocated machine
graphics memory address, it's caught and prevented. We use ballooning to
let guest handle the correctness itself, but having Xen to ensure isolation.

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

correct. 

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

and if you read the paper referred in 1st mail, we call our ballooning as
address space ballooning which is different from traditional ballooning
technique used in memory virtualization, w/ the major difference as:

* traditional ballooning only care about the size. As long as the desired
number of pages can be ballooned out, we don't care whether they
actually come from.

* address space ballooning used in our case care about both size and
address. We need the guest to balloon out a specified range of addresses
as explained earlier.

whether to grow/shrink dynamic is not the key difference between
two approaches. yes, we only support static ballooning now at boot time,
but the same interface can be extended to support dynamic ballooning
in the future, w/ more cooperation from guest driver in the future.

So I think using ballooning is a right fit here, though the policy is very
simple now.

Thanks
Kevin