On Mon, 24 Feb 2020 14:57:43 +0100
Boris Brezillon wrote:
> On Mon, 24 Feb 2020 14:42:31 +0100
> Gerd Hoffmann wrote:
>
> > Hi,
> >
> > > > But let's say we go for a dedicated virtio-device to preserve this
> > > > granularity. Should we aim at providing a generic virtio-msg device or
> >
On Mon, 24 Feb 2020 14:42:31 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > > But let's say we go for a dedicated virtio-device to preserve this
> > > granularity. Should we aim at providing a generic virtio-msg device or
> > > should we keep this so-called wayland-specific virtio device (I'd like
> >
Hi,
> > But let's say we go for a dedicated virtio-device to preserve this
> > granularity. Should we aim at providing a generic virtio-msg device or
> > should we keep this so-called wayland-specific virtio device (I'd like
> > to remind you that it's actually protocol-agnostic)?
>
> Maybe the
Hi,
> But let's say we go for a dedicated virtio-device to preserve this
> granularity. Should we aim at providing a generic virtio-msg device or
> should we keep this so-called wayland-specific virtio device (I'd like
> to remind you that it's actually protocol-agnostic)?
I think it totally ma
On Mon, 24 Feb 2020 13:45:13 +0100
Boris Brezillon wrote:
> On Mon, 24 Feb 2020 13:12:55 +0100
> Gerd Hoffmann wrote:
>
> > On Mon, Feb 24, 2020 at 11:33:48AM +0100, Boris Brezillon wrote:
> > > On Mon, 17 Feb 2020 19:21:50 +0100
> > > Boris Brezillon wrote:
> > >
> > > > > > Thats why
On Mon, 24 Feb 2020 13:12:55 +0100
Gerd Hoffmann wrote:
> On Mon, Feb 24, 2020 at 11:33:48AM +0100, Boris Brezillon wrote:
> > On Mon, 17 Feb 2020 19:21:50 +0100
> > Boris Brezillon wrote:
> >
> > > > > Thats why I don't like the new virtio device idea much and would
> > > > > prefer
> > > >
Hi,
> > Because wayland benefits from allocation and sharing of
> > virtio-gpu buffers, a virtio-gpu combo device simplifies access to
> > those buffers, whereas the separate virtio devices as implemented in
> > crosvm requires bridging of resource handles (in guest kernel) and FDs
> > (in crosv
On Mon, Feb 24, 2020 at 11:33:48AM +0100, Boris Brezillon wrote:
> On Mon, 17 Feb 2020 19:21:50 +0100
> Boris Brezillon wrote:
>
> > > > Thats why I don't like the new virtio device idea much and would prefer
> > > > vhost being reused, either directly (#1) or via proxy (#2).
> > >
> > > For c
On Mon, 17 Feb 2020 19:21:50 +0100
Boris Brezillon wrote:
> > > Thats why I don't like the new virtio device idea much and would prefer
> > > vhost being reused, either directly (#1) or via proxy (#2).
> >
> > For crosvm's purposes, we are looking at ways to reduce vhost usage in
> > order to
On Tue, 18 Feb 2020 13:15:04 -0800
Zach Reizner wrote:
> >> I don't think extending vsock is a
> >> good idea because there's enough going on with virtio-wayland with
> >> respect to FD passing and emulation that a generic interface will be
> >> too opinionated.
> >
> > Can you be more specifi
On Mon, 17 Feb 2020 09:47:46 -0800
Zach Reizner wrote:
> > Thats why I don't like the new virtio device idea much and would prefer
> > vhost being reused, either directly (#1) or via proxy (#2).
>
> For crosvm's purposes, we are looking at ways to reduce vhost usage in
> order to reduce host ker
On Fri, 7 Feb 2020 18:28:42 +0100
Boris Brezillon wrote:
> Based on all previous discussions, I could identify 3 different
> approaches:
>
> 1/ Use VSOCK and extend it to support passing (some) FDs
> 2/ Use a user space VSOCK-based proxy that's in charge of
>a/ passing regular me
On Mon, 17 Feb 2020 13:32:16 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > As pointed in my reply to David's email, I'm a bit worried by the
> > security implications of this approach. As long as the dmabuf -> UUID
> > conversion stays in kernel space we should be safe, but if we start
> > allowing a
Hi,
> As pointed in my reply to David's email, I'm a bit worried by the
> security implications of this approach. As long as the dmabuf -> UUID
> conversion stays in kernel space we should be safe, but if we start
> allowing a guest proxy (running in userland) to send raw UUIDs on a
> VSOCK conn
Hi Stéphane,
On Mon, 10 Feb 2020 12:01:02 -0800
Stéphane Marchesin wrote:
> On Fri, Feb 7, 2020 at 9:28 AM Boris Brezillon <
> boris.brezil...@collabora.com> wrote:
>
> > Hello everyone,
> >
> > I recently took over Tomeu's task of upstreaming virtio-wayland. After
> > spending quite a bit of
Hi Gerd,
Sorry for the delay, I was OOO last week.
On Mon, 10 Feb 2020 14:38:56 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > #1 might require extra care if we want to make it safe, as pointed
> > out by Stefan here [4] (but I wonder if the problem is not the same
> > for a virtio-wayland based sol
> > > FD <-> VFD mappings would have to be created
> > > by the subsystem in charge of the object backing the FD (virtio-gpu for
> > > exported GEM buffers, virtio-vdec for video buffers, vsock for unix
> > > sockets if we decide to bridge unix and vsock sockets to make it
> > > transparent, ...).
Hi David,
On Mon, 10 Feb 2020 14:06:21 +0900
David Stevens wrote:
> > FD <-> VFD mappings would have to be created
> > by the subsystem in charge of the object backing the FD (virtio-gpu for
> > exported GEM buffers, virtio-vdec for video buffers, vsock for unix
> > sockets if we decide to bridg
On Mon, Feb 10, 2020 at 02:38:56PM +0100, Gerd Hoffmann wrote:
> > #3 is pretty similar to #1 in its design except that, instead of using
> > the VSOCK infrastructure it's using a new type of virtio device. I
> > guess it has the same pros and cons #1 has, and the name should probably
> > be change
Hi,
> #1 might require extra care if we want to make it safe, as pointed
> out by Stefan here [4] (but I wonder if the problem is not the same
> for a virtio-wayland based solution). Of course you also need a bit of
> infrastructure to register FD <-> VFD mappings (VFD being a virtual
> file des
> FD <-> VFD mappings would have to be created
> by the subsystem in charge of the object backing the FD (virtio-gpu for
> exported GEM buffers, virtio-vdec for video buffers, vsock for unix
> sockets if we decide to bridge unix and vsock sockets to make it
> transparent, ...). The FD <-> VFD mappi
21 matches
Mail list logo
