Re: [Xen-devel] HVM Driver Domain for GPU API remoting

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Sun, Feb 5, 2012 at 3:38 AM, Michael A. Collins
<mike.a.collins@xxxxxxxxxxx> wrote:
> I recently read about Xen3D and the whole idea of API remoting for graphics
> is new to me, so that's the level I'm coming from.  My question is as
> follows:

I'm not sure anyone here is currently working on API remoting.  It
sounds like you're perhaps suggesting making a new PV frontend/backend
protocol, similar to blockback/front, netback/front, pvscsi, pvusb,
and so on, which would do 3D graphics processing on behalf of guests.
Is that correct?

It sounds like it could be useful to me.  Are you volunteering to
develop such a protocol? :-)

> I understand that graphics passthrough only works for HVM DomUs, with that
> being said most of the driver domains I read about for networking are
> paravirtualized with a passed through NIC.  Is there any work being done to
> introduce the concept of a HVM-based Driver Domain, so that one can pass a
> GPU through?

AIUI, there's no Xen limitation for an HVM guest to be a driver
domain; the main limitation is for the guest to have backend support
when running in HVM mode.  I'm told the work for this has already been
done, and should be available in Linux 3.3 when it comes out.  But I'm
sure you can find the patch series if you're interested.

>  If so, would it not be faster to remote the API through to the
> Driver Domain hosting the GPU with a Xenbus form of communication?

xenbus is not for transmitting bulk data, but configuration
parameters.  The standard method in Xen for transmitting bulk data is
to use xenbus to establish and tear down the communication channels
(shared rings and event channels); the shared rings are used to pass
requests, and the requests contain references to pages that the
frontend wants the backend to operate on directly (the PV equivalent
of DMA).  If you're interested in developing a protocol, it might be
worth looking at the existing protocols, like the network and block
protocols.

 -George

>   My
> concern, other than the fact that I don't understand a thing about how
> Xenbus and other drivers work, is that there wouldn't be the throughput
> needed to provide any better support than is currently handled by the
> virtual framebuffer.  I know that that kind of communication handles all
> block-level and network traffic, but the amount of data required to drive a
> GPU would be much more.  Am I barking up the wrong tree, or is this a
> project that would benefit the community?
>
> Mike
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel