linux-kernel - RE: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

Open Source and information security mailing list archives

Message-ID: <237F54289DF84E4997F34151298ABEBC7C628066@SHSMSX101.ccr.corp.intel.com>
Date:   Wed, 8 Nov 2017 05:21:34 +0000
From:   "Zhang, Tina" <tina.zhang@...el.com>
To:     Gerd Hoffmann <kraxel@...hat.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "chris@...is-wilson.co.uk" <chris@...is-wilson.co.uk>,
        "joonas.lahtinen@...ux.intel.com" <joonas.lahtinen@...ux.intel.com>,
        "zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>,
        "Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
        "Wang, Zhi A" <zhi.a.wang@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "daniel@...ll.ch" <daniel@...ll.ch>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>
CC:     Daniel Vetter <daniel.vetter@...ll.ch>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation


> -----Original Message-----
> From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@...ts.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Tuesday, November 7, 2017 4:03 PM
> To: Zhang, Tina <tina.zhang@...el.com>; alex.williamson@...hat.com;
> chris@...is-wilson.co.uk; joonas.lahtinen@...ux.intel.com;
> zhenyuw@...ux.intel.com; Lv, Zhiyuan <zhiyuan.lv@...el.com>; Wang, Zhi A
> <zhi.a.wang@...el.com>; Tian, Kevin <kevin.tian@...el.com>; daniel@...ll.ch;
> kwankhede@...dia.com
> Cc: Daniel Vetter <daniel.vetter@...ll.ch>; intel-gfx@...ts.freedesktop.org;
> intel-gvt-dev@...ts.freedesktop.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation
> 
>   Hi,
> 
> > > Add a head field here?  People asked @ kvm forum about multihead
> > > support.
> > > Even if the initial driver version doesn't support it we could add a
> > > field so it becomes easier to add it at some point in the future.
> > >
> > > Probing for available heads could be done with the PROBE flag, i.e.
> > > flags = PROBE | DMABUF, plane_type = PRIMARY, head = 0, 1, ...
> >
> > Does the multihead mean multiple display monitor? So each head can
> > have its own one primary plane, one cursor plane and maybe some sprite
> > planes if supported.
> 
> Yes and yes.
> 
> > And the flow could be like this:
> > 1) flags = PROBE | DMABUF, then return the number of heads in
> > vfio_device_gfx_plane_info.head.
> 
> I'd suggest to use { .flags = PROBE | DMABUF, .head = 0 } to check whenever
> dmabuf is supported for head 0, then { .flags = PROBE | DMABUF, .head = 1 } to
> check for head 1 support, ...
> 
> Driver returns success if the head is supported and -EINVAL otherwise, simliar to
> the dmabuf vs. region probing.
> 
> It is less confusing because .head is always an input field then.
> 
> It is also a bit more flexible because different heads can support different modes
> (I don't expect drivers will actually use that though).
> 
> > 2) flags = DMABUF with plane_type = PRIMARY, head = 0, 1, ..., then
> > return the id of the exposed framebuffer of that head.
> 
> Yes.
> 
> > Another question is if the sprite plane is supported, how we're going
> > to identify them, as there could be several sprite planes for one
> > display monitor.
> 
> Do you mean DRM_PLANE_TYPE_OVERLAY?
Yes.

> 
> > Add another field "num_plane" for it? Then, I guess the flow could be
> > like this:
> > 1) flags = PROBE | DMABUF, then return the number of heads in
> > vfio_device_gfx_plane_info.head.
> > 2) flags = PROBE | DMABUF and head = 0, 1, ..., and plane_type =
> > PRIMARY/CURSOR/SPRITE, then return the num_plane.
> 
> I'd suggest to do it simliar to the head probe outlined above, i.e.
> userspace calls { .flags = PROBE | DMABUF, .head = 0, .plane_type = OVERLAY,
> plane_num = 0, 1, 2, ... } and the driver returns -EINVAL or 0 depending on
> whenever it is supported or not.
Agree. Thanks.

BR,
Tina
> 
> cheers,
>   Gerd
> 
> _______________________________________________
> intel-gvt-dev mailing list
> intel-gvt-dev@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives