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.
> 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.
cheers,
Gerd
[1] Not being deeply involved into vgpu development, just reviewing
the bits with some kvm background.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
