search for: virtio_gpu_resource_id

...nking about a struct containing enough info to allow the > proxy on the host side find the buffer, something like: > > struct { > enum type { stdvga, virtio-cpu, ... } > pcislot device; > union { > int stdvga_pcibar_offset; > int virtio_gpu_resource_id; > } > } > > So when the guest proxy gets a message with a fd referencing a buffer it > would have to figure where the buffer is, rewrite the message into the > struct above for the host proxy. The host proxy would rewrite the > message again for the server. What...

On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: > Hi, > >> can we reach agreement on whether vsock should be involved in this? > > I think the best approach would be to have guest proxy and host proxy > use vsock for the wayland protocol. Use a wayland protocol extension to > reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two > proxies need to

On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: > Hi, > >> can we reach agreement on whether vsock should be involved in this? > > I think the best approach would be to have guest proxy and host proxy > use vsock for the wayland protocol. Use a wayland protocol extension to > reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two > proxies need to

...o pass FDs, or something else? I was more thinking about a struct containing enough info to allow the proxy on the host side find the buffer, something like: struct { enum type { stdvga, virtio-cpu, ... } pcislot device; union { int stdvga_pcibar_offset; int virtio_gpu_resource_id; } } So when the guest proxy gets a message with a fd referencing a buffer it would have to figure where the buffer is, rewrite the message into the struct above for the host proxy. The host proxy would rewrite the message again for the server. cheers, Gerd