Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1639250

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

Show all headers | View raw

Hi Alex,

>-----Original Message-----
>From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On
>Behalf Of Alex Williamson
>Sent: Friday, May 05, 2017 11:11 PM
>To: Gerd Hoffmann <kraxel@redhat.com>
>Cc: Tian, Kevin <kevin.tian@intel.com>; intel-gfx@lists.freedesktop.org; linux-
>kernel@vger.kernel.org; zhenyuw@linux.intel.com; Lv, Zhiyuan
><zhiyuan.lv@intel.com>; Chen, Xiaoguang <xiaoguang.chen@intel.com>; intel-
>gvt-dev@lists.freedesktop.org; Wang, Zhi A <zhi.a.wang@intel.com>
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fri, 05 May 2017 08:55:31 +0200
>Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>>   Hi,
>>
>> > > >>Hmm, that looks like a rather strange way to return a file descriptor.
>> > > >>
>> > > >>What is the reason to not use ioctls on the vfio file handle, like
>> > > >>older version of these patches did?
>> > > >If I understood correctly that Alex prefer not to change the
>> > > >ioctls on the vfio file handle like the old version.
>> > > >So I used this way the smallest change to general vfio framework
>> > > >only adding a subregion definition.
>> >
>> > I think I was hoping we could avoid a separate file descriptor
>> > altogether and use a vfio region instead.
>>
>> What exactly did you have in mind?  Put the framebuffer information
>> (struct intel_vgpu_dmabuf) into the vfio region, then access it using
>> read/write/mmap?
>
>Yeah, that was my hope.  Adding a new file descriptor means we have one more
>reference floating around complicating the life cycle of the device, group, and
>container.  Furthermore this one is really only visible to the mdev vendor driver,
>so we can't rely on vfio-core, the vendor driver will need to consider the
>reference when releasing the device.
While read the framebuffer region we have to tell the vendor driver which framebuffer we want to read? There are two framebuffers now in KVMGT that is primary and cursor.
There are two methods to implement this:
1) write the plane id first and then read the framebuffer.
2) create 2 vfio regions one for primary and one for cursor.

Which method do you prefer? Or do you have other idea to handle this problem?

chenxg

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Xiaoguang Chen <xiaoguang.chen@intel.com> - 2017-04-28 11:50 +0200
  Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Gerd Hoffmann <kraxel@redhat.com> - 2017-05-02 12:00 +0200
    RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-05-03 03:50 +0200
      RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-05-04 05:20 +0200
        Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Alex Williamson <alex.williamson@redhat.com> - 2017-05-04 18:10 +0200
          Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Gerd Hoffmann <kraxel@redhat.com> - 2017-05-05 09:00 +0200
            Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Alex Williamson <alex.williamson@redhat.com> - 2017-05-05 17:20 +0200
              RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-05-11 10:50 +0200
                Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Gerd Hoffmann <kraxel@redhat.com> - 2017-05-11 15:30 +0200
                Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Alex Williamson <alex.williamson@redhat.com> - 2017-05-11 17:50 +0200

csiph-web