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

[Chris Wilson]

On Sat, Sep 20, 2014 at 02:47:02AM +0800, Jike Song wrote:
> From: Yu Zhang <yu.c.zhang at intel.com>
> 
> In XenGT, the global graphic memory space is partitioned by multiple
> vgpu instances in different VMs. The ballooning code is added in
> i915_gem_setup_global_gtt(), utilizing the drm mm allocator APIs to
> mark the graphic address space which are partitioned out to other
> vgpus as reserved.
> One special treatment for this scenario is that the guard page is
> added at the end of both aperture and non-aperture spaces. This is
> to follow the behavior pattern in native case. However here we have
> a question: does the prefetch issue mentioned at the begining of
> i915_gem_setup_global_gtt() happens for all the GTT entries, or just
> at then end of the BAR0 space?

The CS prefetcher happens everywhere and so can read from the end of one
range into the beginning of another clients, so requires consideration
if not actualy a guard page. The very last entry in the whole GTT must
be a guard page (or allocated to something not prefetchable).

> If all entries may have prefetch issues,
> then this special guard page is necessary, to protect unexpected
> accesses into GTT entries partitioned out by other VMs. Otherwise,
> we may only need one guard page at the end of the physical GTT space.

I am a bit dubious how this works when userspace still believes that it
can access the whole mappable aperture, and then how every driver
attempts to pin its own planes, rings and whatnot (since it still
believes that it is talking to the actual hardware and that the hardware
requires access to its virtual address). The host should be able to move the
ranges around in order to accommodate userspace in any particular guest
(hence a balloon interface I presume). But I don't see how that is
possible, and you don't explain it either.

The implementation also looks backwards. To work correctly with the GTT
allocator, you need to preallocate the reserved space such that it can
only allocate from the allowed ranges. Similarly, it should evict any
conflicting nodes when deballooning.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre