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