[Intel-gfx] [PATCH v3 3/8] drm/i915: Partition the fence registers for vGPU in i915 driver

[Yu, Zhang]

On 12/17/2014 7:06 PM, Gerd Hoffmann wrote:
>    Hi,
>
>>> It's not possible to allow guests direct access to the fence registers
>>> though.  And if every fence register access traps into the hypervisor
>>> anyway the hypervisor can easily map the guest virtual fence to host
>>> physical fence, so there is no need to tell the guest which fences it
>>> owns, the number of fences is enough.
>>
>> That exactly is the part I don't understand - if it is not required to
>> tell the guest which fences it owns, why it is required to say how many?
>
> There is a fixed assignment of fences to guests, so it's a fixed number.
> But as the hypervisor is involved in any fence access anyway there is no
> need for the guest to know which of the fences it owns, the hypervisor
> can remap that transparently for the guest, without performance penalty.
Thanks Gerd. Exactly.
Although fence registers are parititioned to vGPU, it is not necessary 
for a vGPU to know the physical mmio addresses of the allocated fence 
registers.
For example, vGPU 1 with fence size 4 can access the fence registers 
from 0x100000-10001f; at the same time, vGPU 2 with fence size 8 can 
access the fence registers from 0x100000-0x10003f. Although this seems 
conflicting, it does not matter. Because these mmio addresses are all 
supposed to be trapped in the host side, which will keep a record of the 
real fence offset of different vGPUs(say 0 for vGPU 1 and 4 for vGPU 2), 
and then does the remapping. Therefore, the physical operations on the 
fence register will be performed by host code on different ones(say, 
0x100000-10001fh for vGPU 1 and 0x100020-0x10005f for vGPU 2).
>
>> With this scheme it could be one guest wants more and can't get them
>> even if no one else is using any. If not limited they could be
>> dynamically allocated by the hypervisor, no?
>
> Should be possible as extension, but I think[1] for now the goal is to
> stay as close as possible to physical hardware, where you can't
> dynamically allocate fences in the first place.
Yes. By now we have feature to configure the fence numbers for a vGPU. 
But we do not support the dynamical allocations.
>
> cheers,
>    Gerd
>
> [1] Not being deeply involved into vgpu development, just reviewing
>      the bits with some kvm background.
>
>
>
>
Thanks
Yu