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