[virglrenderer-devel] coherent memory access for virgl

[Tomeu Vizoso]

On 3/8/19 3:02 PM, Tomeu Vizoso wrote:
> On 3/8/19 2:39 PM, Gerd Hoffmann wrote:
>> On Fri, Mar 08, 2019 at 02:10:54PM +0100, Tomeu Vizoso wrote:
>>> On 3/8/19 2:08 PM, Gerd Hoffmann wrote:
>>>> On Fri, Mar 08, 2019 at 10:43:04AM +0100, Tomeu Vizoso wrote:
>>>>> On 10/11/18 1:04 PM, Gerd Hoffmann wrote:
>>>>>>
>>>>>>> * virtio-gpu resource IDs are placed by the guest proxy in the 
>>>>>>> wl_dmabuf
>>>>>>> protocol stream instead of (guest) dmabuf FDs. The proxy in the host
>>>>>>> replaces those to the corresponding (host) dmabuf FD.
>>>>>>
>>>>>> Yes.
>>>>>
>>>>> Hi Gerd,
>>>>>
>>>>> how were you thinking that we would prevent a malicious guest from
>>>>> connecting to the host proxy via VSOCK and guessing virtio-gpu 
>>>>> resource IDs?
>>>>
>>>> Each virtio-gpu device (and therefore each guest) has its own resource
>>>> id namespace, so you can't guess IDs of other guests.  Guessing IDs of
>>>> other processes in the same guest is probably possible.  I think that
>>>> doesn't allow actually accessing these resources, you can only ask the
>>>> host to do something with them.
>>>>
>>>> Maybe that is a good reason do make wayland proxying a virtio-gpu
>>>> extension.  That way guest userspace would not deal with virtio-gpu
>>>> resource IDs but with gbm handles, and the virtio-gpu drm driver would
>>>> translate gbm handles to resource ids before proxying buffer control
>>>> messages to the host side.
>>>
>>> By virtio-gpu extension you mean adding ioctls to send and receive 
>>> protocol
>>> data along with references to buffers?
>>
>> That'll probably work best.  Also a virtio protocol extension.
> 
> Ok, then if you think this is the correct approach, I will work on 
> rebasing the series below:
> 
> https://lkml.org/lkml/2018/1/26/311

Hi Gerd,

do you have any remaining concerns about this approach?

Thanks,

Tomeu