[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DD379D741F77464281CE7ED1CD7C12DE6FC93698@SHSMSX101.ccr.corp.intel.com>
Date: Thu, 4 May 2017 03:09:40 +0000
From: "Chen, Xiaoguang" <xiaoguang.chen@...el.com>
To: "alex.williamson@...hat.com" <alex.williamson@...hat.com>
CC: "Tian, Kevin" <kevin.tian@...el.com>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
"intel-gvt-dev@...ts.freedesktop.org"
<intel-gvt-dev@...ts.freedesktop.org>,
"Wang, Zhi A" <zhi.a.wang@...el.com>,
Gerd Hoffmann <kraxel@...hat.com>
Subject: RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
Hi Alex, do you have any comments for this interface?
>-----Original Message-----
>From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@...ts.freedesktop.org] On
>Behalf Of Chen, Xiaoguang
>Sent: Wednesday, May 03, 2017 9:39 AM
>To: Gerd Hoffmann <kraxel@...hat.com>
>Cc: Tian, Kevin <kevin.tian@...el.com>; intel-gfx@...ts.freedesktop.org; linux-
>kernel@...r.kernel.org; zhenyuw@...ux.intel.com; alex.williamson@...hat.com;
>Lv, Zhiyuan <zhiyuan.lv@...el.com>; intel-gvt-dev@...ts.freedesktop.org; Wang,
>Zhi A <zhi.a.wang@...el.com>
>Subject: RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>
>
>>-----Original Message-----
>>From: Gerd Hoffmann [mailto:kraxel@...hat.com]
>>Sent: Tuesday, May 02, 2017 5:51 PM
>>To: Chen, Xiaoguang <xiaoguang.chen@...el.com>
>>Cc: alex.williamson@...hat.com; intel-gfx@...ts.freedesktop.org;
>>intel-gvt- dev@...ts.freedesktop.org; Wang, Zhi A
>><zhi.a.wang@...el.com>; zhenyuw@...ux.intel.com;
>>linux-kernel@...r.kernel.org; Lv, Zhiyuan <zhiyuan.lv@...el.com>; Tian,
>>Kevin <kevin.tian@...el.com>
>>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the
>>dmabuf
>>
>>On Fr, 2017-04-28 at 17:35 +0800, Xiaoguang Chen wrote:
>>> +static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char
>>> *buf,
>>> + size_t count, loff_t *ppos, bool iswrite) {
>>> + unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
>>> + VFIO_PCI_NUM_REGIONS;
>>> + loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
>>> + int fd;
>>> +
>>> + if (pos >= vgpu->vdev.region[i].size || iswrite) {
>>> + gvt_vgpu_err("invalid op or offset for Intel vgpu fd
>>> region\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + fd = anon_inode_getfd("gvtg", &intel_vgpu_gvtg_ops, vgpu,
>>> + O_RDWR | O_CLOEXEC);
>>> + if (fd < 0) {
>>> + gvt_vgpu_err("create intel vgpu fd failed:%d\n", fd);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
>>> + memcpy(buf, &fd, count);
>>> +
>>> + return count;
>>> +}
>>
>>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.
>
>>
>>cheers,
>> Gerd
>
>_______________________________________________
>intel-gvt-dev mailing list
>intel-gvt-dev@...ts.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
Powered by blists - more mailing lists