a.com>; intel-gvt-
> d...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Thu, Jun 29, 2017 at 08:41:53AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > Does gvt track the live
vger.kernel.org; Chen, Xiaoguang
> ; Zhang, Tina ; Alex
> Williamson ; Lv, Zhiyuan
> ; Kirti Wankhede ; intel-gvt-
> d...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Thu, Jun 29, 2017 at 08:41:53AM +0200, Gerd H
On Thu, Jun 29, 2017 at 08:41:53AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Does gvt track the live cycle of all dma-bufs it has handed out?
> >
> > The V9 implementation does track the dma-bufs' live cycle. The
> > original idea was that leaving the dma-bufs' live cycle management to
> >
On Thu, Jun 29, 2017 at 08:41:53AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Does gvt track the live cycle of all dma-bufs it has handed out?
> >
> > The V9 implementation does track the dma-bufs' live cycle. The
> > original idea was that leaving the dma-bufs' live cycle management to
> >
Hi,
> > Does gvt track the live cycle of all dma-bufs it has handed out?
>
> The V9 implementation does track the dma-bufs' live cycle. The
> original idea was that leaving the dma-bufs' live cycle management to
> user mode.
That is still the case, user space decides which dma-bufs it'll go
Hi,
> > Does gvt track the live cycle of all dma-bufs it has handed out?
>
> The V9 implementation does track the dma-bufs' live cycle. The
> original idea was that leaving the dma-bufs' live cycle management to
> user mode.
That is still the case, user space decides which dma-bufs it'll go
.org; Wang, Zhi A <zhi.a.w...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> Hi,
>
> > Hmm, I don't like that interface. Can you cite examples of other
> > ioctls that behave this way? It does
vger.kernel.org; Chen, Xiaoguang
> ; Zhang, Tina ; Kirti
> Wankhede ; Lv, Zhiyuan ;
> intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> Hi,
>
> > Hmm, I don't like that in
Hi,
> Hmm, I don't like that interface. Can you cite examples of other
> ioctls that behave this way? It doesn't feel like an elegant user
> interface; the user can get the dmabuf, but only after they query the
> dmabuf, even though the get-dmabuf ioctl returns the same data as the
>
Hi,
> Hmm, I don't like that interface. Can you cite examples of other
> ioctls that behave this way? It doesn't feel like an elegant user
> interface; the user can get the dmabuf, but only after they query the
> dmabuf, even though the get-dmabuf ioctl returns the same data as the
>
On Mon, 26 Jun 2017 08:39:17 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > With the generation we can also do something different: Pass in
> > > plane_type and
> > > generation, and have VFIO_DEVICE_GET_DMABUF_FD return an error in
> > > case
> > > the generation doesn't match.
On Mon, 26 Jun 2017 08:39:17 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > With the generation we can also do something different: Pass in
> > > plane_type and
> > > generation, and have VFIO_DEVICE_GET_DMABUF_FD return an error in
> > > case
> > > the generation doesn't match. In that case it
Hi,
> > With the generation we can also do something different: Pass in
> > plane_type and
> > generation, and have VFIO_DEVICE_GET_DMABUF_FD return an error in
> > case
> > the generation doesn't match. In that case it doesn't make much
> > sense any
> > more to have a separate plane_info
Hi,
> > With the generation we can also do something different: Pass in
> > plane_type and
> > generation, and have VFIO_DEVICE_GET_DMABUF_FD return an error in
> > case
> > the generation doesn't match. In that case it doesn't make much
> > sense any
> > more to have a separate plane_info
Hi,
> > So maybe a "enum plane_state" (instead of "bool is_enabled")? So
> > we
> > can clearly disturgish ENABLED, DISABLED, NOT_SUPPORTED cases?
>
> What's the difference between NOT_SUPPORTED and -ENOTTY on the ioctl?
> Perhaps a bit in a flags field could specify EN/DIS-ABLED and leave
>
Hi,
> > So maybe a "enum plane_state" (instead of "bool is_enabled")? So
> > we
> > can clearly disturgish ENABLED, DISABLED, NOT_SUPPORTED cases?
>
> What's the difference between NOT_SUPPORTED and -ENOTTY on the ioctl?
> Perhaps a bit in a flags field could specify EN/DIS-ABLED and leave
>
r.kernel.org; Kirti
> Wankhede <kwankh...@nvidia.com>; Chen, Xiaoguang
> <xiaoguang.c...@intel.com>; intel-gvt-...@lists.freedesktop.org; Lv, Zhiyuan
> <zhiyuan...@intel.com>; Wang, Zhi A <zhi.a.w...@intel.com>; Wang, Zhenyu
> Z <zhenyu.z.w...@intel.com>
&
aoguang
> ; intel-gvt-...@lists.freedesktop.org; Lv, Zhiyuan
> ; Wang, Zhi A ; Wang, Zhenyu
> Z
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote:
> > Hi,
> >
> > Thanks for all the commen
On Fri, 23 Jun 2017 09:26:59 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > Is this only going to support accelerated driver output, not basic
> > VGA
> > modes for BIOS interaction?
>
> Right now there is no vgabios or uefi support for the vgpu.
>
> But even with that in place
On Fri, 23 Jun 2017 09:26:59 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > Is this only going to support accelerated driver output, not basic
> > VGA
> > modes for BIOS interaction?
>
> Right now there is no vgabios or uefi support for the vgpu.
>
> But even with that in place there still is the
On Fri, 23 Jun 2017 10:31:28 +0200
Gerd Hoffmann wrote:
> On Fri, 2017-06-23 at 15:49 +0800, Zhi Wang wrote:
> > Hi:
> > Thanks for the discussions! If the userspace application has
> > already maintained a LRU list, it looks like we don't need
> > generation
> >
On Fri, 23 Jun 2017 10:31:28 +0200
Gerd Hoffmann wrote:
> On Fri, 2017-06-23 at 15:49 +0800, Zhi Wang wrote:
> > Hi:
> > Thanks for the discussions! If the userspace application has
> > already maintained a LRU list, it looks like we don't need
> > generation
> > anymore,
>
>
Hi Gred and Alex:
Thanks for the reply! It would be better that kernel only provides
functions instead of maintaining states from my point of view. If there
is any existing async notification channel in vfio device fd? like
reporting device events from vfio to QEMU? If so, It would be nice
Hi Gred and Alex:
Thanks for the reply! It would be better that kernel only provides
functions instead of maintaining states from my point of view. If there
is any existing async notification channel in vfio device fd? like
reporting device events from vfio to QEMU? If so, It would be nice
On Fri, 2017-06-23 at 15:49 +0800, Zhi Wang wrote:
> Hi:
> Thanks for the discussions! If the userspace application has
> already maintained a LRU list, it looks like we don't need
> generation
> anymore,
generation isn't required, things are working just fine without that.
It is just a
On Fri, 2017-06-23 at 15:49 +0800, Zhi Wang wrote:
> Hi:
> Thanks for the discussions! If the userspace application has
> already maintained a LRU list, it looks like we don't need
> generation
> anymore,
generation isn't required, things are working just fine without that.
It is just a
Hi:
Thanks for the discussions! If the userspace application has
already maintained a LRU list, it looks like we don't need generation
anymore, as userspace application will lookup the guest framebuffer from
the LRU list by "offset". No matter how, it would know if this is a new
guest
Hi:
Thanks for the discussions! If the userspace application has
already maintained a LRU list, it looks like we don't need generation
anymore, as userspace application will lookup the guest framebuffer from
the LRU list by "offset". No matter how, it would know if this is a new
guest
Hi,
> Is this only going to support accelerated driver output, not basic
> VGA
> modes for BIOS interaction?
Right now there is no vgabios or uefi support for the vgpu.
But even with that in place there still is the problem that the display
device initialization happens before the guest runs
Hi,
> Is this only going to support accelerated driver output, not basic
> VGA
> modes for BIOS interaction?
Right now there is no vgabios or uefi support for the vgpu.
But even with that in place there still is the problem that the display
device initialization happens before the guest runs
On Thu, 22 Jun 2017 10:30:15 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > VFIO_DEVICE_FLAGS_GFX_DMABUF?
> >
> > After proposing these, I'm kind of questioning their purpose. In the
> > case of a GFX region, the user is going to learn that this is
> > supported
> > as they
On Thu, 22 Jun 2017 10:30:15 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > VFIO_DEVICE_FLAGS_GFX_DMABUF?
> >
> > After proposing these, I'm kind of questioning their purpose. In the
> > case of a GFX region, the user is going to learn that this is
> > supported
> > as they parse the region
Hi,
> > VFIO_DEVICE_FLAGS_GFX_DMABUF?
>
> After proposing these, I'm kind of questioning their purpose. In the
> case of a GFX region, the user is going to learn that this is
> supported
> as they parse the region information and find the device specific
> region identifying itself as a GFX
Hi,
> > VFIO_DEVICE_FLAGS_GFX_DMABUF?
>
> After proposing these, I'm kind of questioning their purpose. In the
> case of a GFX region, the user is going to learn that this is
> supported
> as they parse the region information and find the device specific
> region identifying itself as a GFX
op.org; Wang,
> Zhi A <zhi.a.w...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Wed, 2017-06-21 at 09:20 +, Zhang, Tina wrote:
> > Thanks for all the comments. I'm planning to cook the next version of
>
esktop.org; linux-kernel@vger.kernel.org; Chen, Xiaoguang
> ; Kirti Wankhede ; Lv,
> Zhiyuan ; intel-gvt-...@lists.freedesktop.org; Wang,
> Zhi A
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Wed, 2017-06-21 at 09:20 +, Zhang, Tin
On Wed, 21 Jun 2017 13:03:31 +0200
Gerd Hoffmann wrote:
> On Wed, 2017-06-21 at 09:20 +, Zhang, Tina wrote:
> > Thanks for all the comments. I'm planning to cook the next version of
> > this patch set
>
> How about posting only this patch instead of the whole series
On Wed, 21 Jun 2017 13:03:31 +0200
Gerd Hoffmann wrote:
> On Wed, 2017-06-21 at 09:20 +, Zhang, Tina wrote:
> > Thanks for all the comments. I'm planning to cook the next version of
> > this patch set
>
> How about posting only this patch instead of the whole series until
> we've settled
On Wed, 2017-06-21 at 09:20 +, Zhang, Tina wrote:
> Thanks for all the comments. I'm planning to cook the next version of
> this patch set
How about posting only this patch instead of the whole series until
we've settled the interfaces?
> Could the following two works?
> #define
On Wed, 2017-06-21 at 09:20 +, Zhang, Tina wrote:
> Thanks for all the comments. I'm planning to cook the next version of
> this patch set
How about posting only this patch instead of the whole series until
we've settled the interfaces?
> Could the following two works?
> #define
gt;; intel-...@lists.freedesktop.org;
> linux-kernel@vger.kernel.org; Kirti Wankhede <kwankh...@nvidia.com>;
> Chen, Xiaoguang <xiaoguang.c...@intel.com>; intel-gvt-
> d...@lists.freedesktop.org; Lv, Zhiyuan <zhiyuan...@intel.com>; Wang, Zhi A
> <zhi.a.w...@
nel@vger.kernel.org; Kirti Wankhede ;
> Chen, Xiaoguang ; intel-gvt-
> d...@lists.freedesktop.org; Lv, Zhiyuan ; Wang, Zhi A
> ; Wang, Zhenyu Z
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Tue, 20 Jun 2017 23:01:53 +
>
Hi,
> We already have VFIO_DEVICE_GET_INFO which returns:
>
> struct vfio_device_info {
> __u32 argsz;
> __u32 flags;
> #define VFIO_DEVICE_FLAGS_RESET (1 << 0)/* Device supports
> reset */
> #define VFIO_DEVICE_FLAGS_PCI (1 << 1)/* vfio-pci device */
>
Hi,
> We already have VFIO_DEVICE_GET_INFO which returns:
>
> struct vfio_device_info {
> __u32 argsz;
> __u32 flags;
> #define VFIO_DEVICE_FLAGS_RESET (1 << 0)/* Device supports
> reset */
> #define VFIO_DEVICE_FLAGS_PCI (1 << 1)/* vfio-pci device */
>
gt; Lv, Zhiyuan <zhiyuan...@intel.com>; Wang, Zhi A <zhi.a.w...@intel.com>;
> > Wang, Zhenyu Z <zhenyu.z.w...@intel.com>
> > Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> > operations
> >
> > On Tue, 20 Jun 20
sts.freedesktop.org;
> > linux-
> > ker...@vger.kernel.org; Kirti Wankhede ; Chen,
> > Xiaoguang ; intel-gvt-...@lists.freedesktop.org;
> > Lv, Zhiyuan ; Wang, Zhi A ;
> > Wang, Zhenyu Z
> > Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> &g
.@vger.kernel.org; Kirti Wankhede <kwankh...@nvidia.com>; Chen,
> Xiaoguang <xiaoguang.c...@intel.com>; intel-gvt-...@lists.freedesktop.org;
> Lv, Zhiyuan <zhiyuan...@intel.com>; Wang, Zhi A <zhi.a.w...@intel.com>;
> Wang, Zhenyu Z <zhenyu.z.w...@intel.com>
&
t; Xiaoguang ; intel-gvt-...@lists.freedesktop.org;
> Lv, Zhiyuan ; Wang, Zhi A ;
> Wang, Zhenyu Z
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Tue, 20 Jun 2017 12:57:36 +0200
> Gerd Hoffmann wrote:
>
> > On Tue,
On 6/20/2017 8:30 PM, Alex Williamson wrote:
> On Tue, 20 Jun 2017 12:57:36 +0200
> Gerd Hoffmann wrote:
>
>> On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote:
>>> Hi,
>>>
>>> Thanks for all the comments. Here are the summaries:
>>>
>>> 1. Modify the structures to make
On 6/20/2017 8:30 PM, Alex Williamson wrote:
> On Tue, 20 Jun 2017 12:57:36 +0200
> Gerd Hoffmann wrote:
>
>> On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote:
>>> Hi,
>>>
>>> Thanks for all the comments. Here are the summaries:
>>>
>>> 1. Modify the structures to make it more general.
>>>
On Tue, 20 Jun 2017 12:57:36 +0200
Gerd Hoffmann wrote:
> On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote:
> > Hi,
> >
> > Thanks for all the comments. Here are the summaries:
> >
> > 1. Modify the structures to make it more general.
> > struct
On Tue, 20 Jun 2017 12:57:36 +0200
Gerd Hoffmann wrote:
> On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote:
> > Hi,
> >
> > Thanks for all the comments. Here are the summaries:
> >
> > 1. Modify the structures to make it more general.
> > struct vfio_device_gfx_plane_info {
> > __u64
On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote:
> Hi,
>
> Thanks for all the comments. Here are the summaries:
>
> 1. Modify the structures to make it more general.
> struct vfio_device_gfx_plane_info {
> __u64 start;
> __u64 drm_format_mod;
> __u32 drm_format;
>
On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote:
> Hi,
>
> Thanks for all the comments. Here are the summaries:
>
> 1. Modify the structures to make it more general.
> struct vfio_device_gfx_plane_info {
> __u64 start;
> __u64 drm_format_mod;
> __u32 drm_format;
>
kernel.org; Kirti
> Wankhede <kwankh...@nvidia.com>; Chen, Xiaoguang
> <xiaoguang.c...@intel.com>; intel-gvt-...@lists.freedesktop.org; Lv, Zhiyuan
> <zhiyuan...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
khede ; Chen, Xiaoguang
> ; intel-gvt-...@lists.freedesktop.org; Lv, Zhiyuan
>
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Mon, 19 Jun 2017 08:38:32 +0200
> Gerd Hoffmann wrote:
>
> > Hi,
> >
> > >
56 matches
Mail list logo