Hi,
I'll try to do the detailed review of your series in the following few days. I might ask some questions on the design also to help me understand the bigger picture.
First thing, I see that patches are checkpatch.pl clean, apart when run in strict mode. I think Daniel prefers "--strict" nowadays, at least I needed to fix up those in my patches so you should probably do the same.
On 11/13/2014 12:02 PM, Yu Zhang wrote: [snip]
The primary change introduced here is to implement so-called "address space ballooning" technique. XenGT partitions global graphics memory among multiple VMs, so each VM can directly access a portion of the memory w/o hypervisor's intervention, e.g. filling textures or queuing commands. However w/ the partitioning an unmodified i915 driver would assume a smaller graphics memory starting from address ZERO, so requires XenGT core module (vgt) to translate the graphics address between 'guest view' and 'host view', for all registers and command opcodes which contain a graphics memory address. To reduce the complexity, XenGT introduces "address space ballooning", by telling the exact partitioning knowledge to each guest i915 driver, which then reserves and prevents non-allocated portions from allocation. Then vgt module only needs to scan and validate graphics addresses w/o complexity of translation.
I couldn't figure this out - is there any hardware protection in there, or a virtual i915 instance could access memory outside it's area if there was a security bug/exploit in the driver, or the balloon was incorrectly set up?
Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
