On Sat, Sep 20, 2014 at 02:47:02AM +0800, Jike Song wrote: > From: Yu Zhang <yu.c.zhang@xxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
