Re: [PATCH v3 0/8] Add enlightenments for vGPU

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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