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

[Gerd Hoffmann]

  Hi,

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

> Unless there are plan to make it grow and shrink it seems that we agree 
> it is confusing. But I suppose it is too late to change the term now?

It's confusing indeed (same question came up @ kvm forum after kvmgt
presentation).  So a better name would be good I think.

cheers,
  Gerd