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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
