Hi,
> > > Right we need to know this at device initialization time for both
> > > cases
> > > to initialize VGACommonState structure for that device
> >
> > Why do you need a VGACommonState?
> >
>
> We need to create a GRAPHIC_CONSOLE for vGPU device and specify
> GraphicHwOps so that from it
Hey Gerd,
Sorry, I missed this mail earlier.
On 6/21/2017 12:52 PM, Gerd Hoffmann wrote:
> Hi,
>
>> We don't support cursor for console vnc. Ideally console vnc should
>> be
>> used by admin for configuration or during maintenance, which refresh
>> primary surface at low refresh rate, 10 fps.
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
> > user
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 ke
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
> query-pla
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 do
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 str
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
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 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
> > anymore,
>
> generation
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 sm
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 fram
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 a
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 info
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 ar
eedesktop.org; linux-ker...@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 until
> we've settled t
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 VFIO_DEVICE_F
linux-ker...@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 */
> #de
Hi,
> We don't support cursor for console vnc. Ideally console vnc should
> be
> used by admin for configuration or during maintenance, which refresh
> primary surface at low refresh rate, 10 fps.
But you surely want a mouse pointer for the admin?
You render it directly to the primary surface t
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
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 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 vfio_device_gfx_plane_info {
> > __u64 st
On 6/20/2017 2:05 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> Hmm, plane isn't really an ID, it is a type, with type being either
>>> DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think
>>> the
>>> flage above make sense.
>>
>> The intention was that ..._REGION_ID and ...PLANE_ID are de
On 6/19/2017 8:25 PM, Alex Williamson wrote:
> On Mon, 19 Jun 2017 08:38:32 +0200
> Gerd Hoffmann wrote:
>
>> Hi,
>>
>>> My suggestion was to use vfio device fd for this ioctl and have
>>> dmabuf
>>> mgr fd as member in above query_plane structure, for region type it
>>> would be set to 0.
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;
> __u
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,
> >
> > >
Hi,
> > Hmm, plane isn't really an ID, it is a type, with type being either
> > DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think
> > the
> > flage above make sense.
>
> The intention was that ..._REGION_ID and ...PLANE_ID are describing
> what the vfio_device_query_gfx_plane.id
On Mon, 19 Jun 2017 08:38:32 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > My suggestion was to use vfio device fd for this ioctl and have
> > dmabuf
> > mgr fd as member in above query_plane structure, for region type it
> > would be set to 0.
>
> Region type should be DRM_PLANE_TYPE_PRIMARY
>
>
On Mon, 19 Jun 2017 08:34:13 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > So perhaps this becomes:
> >
> > struct vfio_device_gfx_plane_info {
> > __u64 start;
> > __u64 drm_format_mod;
> > __u32 drm_format;
> > __u32 width;
> > __u32 height;
> > __u32 stride;
> > __u32
Hi,
> So perhaps this becomes:
>
> struct vfio_device_gfx_plane_info {
> __u64 start;
> __u64 drm_format_mod;
> __u32 drm_format;
> __u32 width;
> __u32 height;
> __u32 stride;
> __u32 size;
> __u32 x_pos;
> __u32 y_pos;
> };
Looks good.
>
Hi,
> My suggestion was to use vfio device fd for this ioctl and have
> dmabuf
> mgr fd as member in above query_plane structure, for region type it
> would be set to 0.
Region type should be DRM_PLANE_TYPE_PRIMARY
> Can't mmap that page to get surface information. There is no way to
> synchro
On 6/16/2017 10:09 PM, Alex Williamson wrote:
> On Fri, 16 Jun 2017 19:02:30 +0530
> Kirti Wankhede wrote:
>
>> On 6/16/2017 2:08 AM, Alex Williamson wrote:
>>> On Thu, 15 Jun 2017 18:00:38 +0200
>>> Gerd Hoffmann wrote:
>>>
Hi,
>> +struct vfio_dmabuf_mgr_plane_info {
On Fri, 16 Jun 2017 19:02:30 +0530
Kirti Wankhede wrote:
> On 6/16/2017 2:08 AM, Alex Williamson wrote:
> > On Thu, 15 Jun 2017 18:00:38 +0200
> > Gerd Hoffmann wrote:
> >
> >> Hi,
> >>
> +struct vfio_dmabuf_mgr_plane_info {
> +__u64 start;
> +__u64 drm_form
On 6/16/2017 2:08 AM, Alex Williamson wrote:
> On Thu, 15 Jun 2017 18:00:38 +0200
> Gerd Hoffmann wrote:
>
>> Hi,
>>
+struct vfio_dmabuf_mgr_plane_info {
+ __u64 start;
+ __u64 drm_format_mod;
+ __u32 drm_format;
+ __u32 width;
+ __u32 height;
+ __u32
On Fri, 16 Jun 2017 12:24:42 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > I'm not sure I agree regarding the vgpu statement, maybe this is not
> > dmabuf specific, but what makes it vgpu specific? We need to
> > separate
> > our current usage plans from what it's actually describing and I
> > don't
Hi,
> I'm not sure I agree regarding the vgpu statement, maybe this is not
> dmabuf specific, but what makes it vgpu specific? We need to
> separate
> our current usage plans from what it's actually describing and I
> don't
> see that it describes anything vgpu specific.
Well, it describes a f
On Thu, 15 Jun 2017 18:00:38 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > +struct vfio_dmabuf_mgr_plane_info {
> > > + __u64 start;
> > > + __u64 drm_format_mod;
> > > + __u32 drm_format;
> > > + __u32 width;
> > > + __u32 height;
> > > + __u32 stride;
> > > + __u32 size;
> > > + __u32 x_pos;
> >
Hi,
> > +struct vfio_dmabuf_mgr_plane_info {
> > + __u64 start;
> > + __u64 drm_format_mod;
> > + __u32 drm_format;
> > + __u32 width;
> > + __u32 height;
> > + __u32 stride;
> > + __u32 size;
> > + __u32 x_pos;
> > + __u32 y_pos;
> > + __u32 padding;
> > +};
> > +
>
> This
On 6/15/2017 1:30 PM, Xiaoguang Chen wrote:
> Here we defined a new ioctl to create a fd for a vfio device based on
> the input type. Now only one type is supported that is a dma-buf
> management fd.
> Two ioctls are defined for the dma-buf management fd: query the vfio
> vgpu's plane information
Here we defined a new ioctl to create a fd for a vfio device based on
the input type. Now only one type is supported that is a dma-buf
management fd.
Two ioctls are defined for the dma-buf management fd: query the vfio
vgpu's plane information and create a dma-buf for a plane.
Signed-off-by: Xiaog
46 matches
Mail list logo