Hi,
> Or more simply just pass the plane id, because even the plane description did
> not match the current one we will eventually create a dmabuf based on current
> plane.
That is the current behavior.
Works as long as we return the plane description too, so userspace knows
what it actually
Alex Williamson ; Lv,
>Zhiyuan ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi
>A
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
> Hi,
>
>> >We could also do it the other way around: Instead of having the
>> >kernel returning
>>
Hi,
> >We could also do it the other way around: Instead of having the kernel
> >returning
>
> >the plane description userspace could pass it in, and the kernel throws
> >-EINVAL in
>
> >case it doesn't match due to things having changed meanwhile.
>
> Or just return a dmabuf based on the
lists.freedesktop.org; Wang,
>Zhi A
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
> Hi,
>
>> > User space need to check whether there's a dmabuf for the plane(user space
>usually cached two or three dmabuf to handle double buffer or tri
Hi,
> > User space need to check whether there's a dmabuf for the plane(user space
> > usually cached two or three dmabuf to handle double buffer or triple buffer
> > situation) only there's no dmabuf for the plane we will create a dmabuf for
> > it(another ioctl).
>
> If our ioctls are "Que
freedesktop.org; Wang, Zhi A
>
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Thu, 18 May 2017 01:51:38 +
>"Chen, Xiaoguang" wrote:
>
>> Hi Alex,
>>
>> >-Original Message-
>> >From: Alex Williams
Gerd Hoffmann ; Tian, Kevin ;
> >linux-kernel@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
> >; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> >
> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
> >
> >On Tue, 16 May 2017 10:16:28
Hi,
> > +static long intel_vgpu_dmabuf_mgr_fd_ioctl(struct file *filp,
> > + unsigned int ioctl, unsigned long arg)
> > +{
> > + struct intel_vgpu *vgpu = filp->private_data;
> > + int minsz;
> > + struct intel_vgpu_dmabuf dmabuf;
> > + int ret;
> > +
lists.freedesktop.org; Wang, Zhi A
>
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Tue, 16 May 2017 10:16:28 +
>"Chen, Xiaoguang" wrote:
>
>> Hi Alex,
>>
>> >-Original Message-
>> >From: Alex W
>Cc: Gerd Hoffmann ; Tian, Kevin ;
> >intel-...@lists.freedesktop.org; linux-kernel@vger.kernel.org;
> >zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt-
> >d...@lists.freedesktop.org; Wang, Zhi A
> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
> >
> >
ntel.com; Lv, Zhiyuan ; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Mon, 15 May 2017 03:36:50 +
>"Chen, Xiaoguang" wrote:
>
>> Hi Alex and Gerd,
>>
>> >---
t;Cc: Chen, Xiaoguang ; Tian, Kevin
> >; intel-...@lists.freedesktop.org; linux-
> >ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
> >; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> >
> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting
.@linux.intel.com; Lv, Zhiyuan
>; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
>
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fri, 12 May 2017 11:12:05 +0200
>Gerd Hoffmann wrote:
>
>> Hi,
>>
>> > If the cont
t; >To: Chen, Xiaoguang
> >Cc: Tian, Kevin ; intel-...@lists.freedesktop.org;
> >linux-
> >ker...@vger.kernel.org; zhen...@linux.intel.com; Alex Williamson
> >; Lv, Zhiyuan ; intel-gvt-
> >d...@lists.freedesktop.org; Wang, Zhi A
> >Subject: Re: [RFC PATCH 6/6
On Fri, 12 May 2017 11:12:05 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > If the contents of the framebuffer change or if the parameters of the
> > framebuffer change? I can't image that creating a new dmabuf fd for
> > every visual change within the framebuffer would be efficient, but I
> > don't
Hi,
> If the contents of the framebuffer change or if the parameters of the
> framebuffer change? I can't image that creating a new dmabuf fd for
> every visual change within the framebuffer would be efficient, but I
> don't have any concept of what a dmabuf actually does.
Ok, some background:
vger.kernel.org; zhen...@linux.intel.com; Alex Williamson
>; Lv, Zhiyuan ; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
> Hi,
>
>> While read the framebuffer region we have to tell the vendor driver
, Zhiyuan ; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fri, 12 May 2017 02:12:10 +
>"Chen, Xiaoguang" wrote:
>
>> Hi Alex and Gerd,
>>
>> >-Origin
:45 PM
> >To: Gerd Hoffmann
> >Cc: Tian, Kevin ; intel-...@lists.freedesktop.org;
> >linux-
> >ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
> >; Chen, Xiaoguang ; intel-
> >gvt-...@lists.freedesktop.org; Wang, Zhi A
> >Subject: Re: [RFC P
vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>; Chen, Xiaoguang ; intel-
>gvt-...@lists.freedesktop.org; Wang, Zhi A
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Thu, 11 May 2017 15:27:53 +0200
>Gerd Hoffmann wrote:
>
>>
On Thu, 11 May 2017 15:27:53 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > 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:
Hi,
> 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) crea
vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>; Chen, Xiaoguang ; intel-
>gvt-...@lists.freedesktop.org; Wang, Zhi A
>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 wrote:
>
>> Hi,
>>
On Fri, 05 May 2017 08:55:31 +0200
Gerd Hoffmann 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 underst
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
;>To: Chen, Xiaoguang
> >>Cc: alex.william...@redhat.com; intel-...@lists.freedesktop.org;
> >>intel-gvt- d...@lists.freedesktop.org; Wang, Zhi A
> >>; zhen...@linux.intel.com;
> >>linux-kernel@vger.kernel.org; Lv, Zhiyuan ; Tian,
> >>Kevin
> &
ts.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; alex.william...@redhat.com;
>Lv, Zhiyuan ; intel-gvt-...@lists.freedesktop.org; Wang,
>Zhi A
>Subject: RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>
>
>>-Original M
tel.com; linux-kernel@vger.kernel.org; Lv, Zhiyuan
>; Tian, Kevin
>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
>>
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_
29 matches
Mail list logo
