hat when necessary the GEM
> object can be initialized in between. I think that's slightly more
> flexible and easier to understand than a boolean flag.
Yes, that should work too.
Acked-by: Gerd Hoffmann
cheers,
Gerd
___
Intel-gfx mailing list
No need for a home-grown version, the generic helper should work just
fine. It also handles vgacon removal these days, see commit
1c74ca7a1a9a ("drm/fb-helper: call vga_remove_vgacon automatically."),
so that can be removed too.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/
> I applied the following fix patch:
>
> From: Stephen Rothwell
> Date: Wed, 28 Aug 2019 18:37:40 +1000
> Subject: [PATCH] drm/virtio: module_param_named() requires linux/moduleparam.h
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 2 ++
> 1 file changed,
On Tue, Dec 01, 2020 at 11:35:26AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert bochs to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:27AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert cirrus to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:36AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert qxl to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Tue, Dec 01, 2020 at 11:35:40AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert virtgpu to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Gerd Hoffmann
Acked
On Thu, Oct 29, 2020 at 11:14:28AM +0100, Daniel Vetter wrote:
> These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
> emulation code").
Acked-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freed
On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote:
> Exactly matches the one in the helpers.
>
> This avoids me having to roll out dma-fence critical section
> annotations to this copy.
>
> Signed-off-by: Daniel Vetter
> Cc: David Airlie
> Cc: Gerd Hof
On Wed, Aug 19, 2020 at 02:43:28PM +0200, Jiri Slaby wrote:
> On 09. 07. 20, 14:33, Daniel Vetter wrote:
> > Exactly matches the one in the helpers.
>
> It's not that exact. The order of modeset_enables and planes is
> different. And this causes a regression -- no fb in qemu.
Does https://patchwo
On Thu, Aug 20, 2020 at 08:32:51AM +0200, Jiri Slaby wrote:
> On 19. 08. 20, 15:24, Gerd Hoffmann wrote:
> > On Wed, Aug 19, 2020 at 02:43:28PM +0200, Jiri Slaby wrote:
> >> On 09. 07. 20, 14:33, Daniel Vetter wrote:
> >>> Exactly matches the one in the helpers.
>
m_device and the drmm_ stuff.
Acked-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Feb 19, 2020 at 11:20:58AM +0100, Daniel Vetter wrote:
> Small mistake that crept into
>
> commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab
> Author: Gerd Hoffmann
> Date: Tue Feb 11 14:52:18 2020 +0100
>
> drm/bochs: add drm_driver.releas
>
> Signed-off-by: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
Acked-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Feb 19, 2020 at 11:21:00AM +0100, Daniel Vetter wrote:
> We can even delete the drm_driver.release hook now!
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnb
Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Emil Velikov
> Cc: Thomas Zimmermann
> Cc: virtualizat...@lists.linux-foundation.org
Acked-by: Gerd Hoffmann
___
Int
c(). We need to remove the kfree from
> xen_drm_drv_release().
>
> bochs also has a release hook, but leaked the drm_device ever since
>
> commit 0a6659bdc5e8221da99eebb176fd9591435e38de
> Author: Gerd Hoffmann
> Date: Tue Dec 17 18:04:46 2013 +0100
>
> drm/bochs:
On Mon, Mar 02, 2020 at 11:25:47PM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
Acked-by: Gerd Hoffmann
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.
kfree(cirrus);
> + goto err_pci_release;
> + }
> dev->dev_private = cirrus;
> + drmm_add_final_kfree(dev, cirrus);
That doesn't look like an error path improvement.
With patch #30 applied it'll looks alot better though.
So maybe squash
On Mon, Mar 02, 2020 at 11:26:07PM +0100, Daniel Vetter wrote:
> Small mistake that crept into
>
> commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab
> Author: Gerd Hoffmann
> Date: Tue Feb 11 14:52:18 2020 +0100
>
> drm/bochs: add drm_driver.releas
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init(
_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
Acked-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Mar 02, 2020 at 11:26:10PM +0100, Daniel Vetter wrote:
> With the drm_device lifetime fun cleaned up there's nothing in the way
> anymore to use devm_ for everything hw releated. Do it, and in the
> process, throw out the entire onion unwinding.
Acked-by:
Hi,
> [Zhang, Xiong Y] Thanks for your teach and propose.
> For smbios, could you teach me which type and field could be used ?
qemu adds a specific subsystem id to all virtual devices, so you can use
that to figure you are running on qemu. One good candidate to check is
the host bridge (easy
Hi,
> > +#ifndef _GVT_DMABUF_H_
> > +#define _GVT_DMABUF_H_
> > +
> > +#define INTEL_VGPU_QUERY_DMABUF0
> > +#define INTEL_VGPU_GENERATE_DMABUF 1
> > +
> > +struct intel_vgpu_dmabuf {
>
> This looks to be uapi. What's it doing here?
It is indeed, should go to include/uapi/
cheers,
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_
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
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
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:
On Tue, Aug 07, 2018 at 07:36:47PM +0100, Chris Wilson wrote:
> Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), the core provides the no-op functions when map and
> map_atomic are not provided, so we no longer need assert that are
> supplied by a dma-buf
> We want to get rid of plane->fb on atomic drivers. Stop setting it.
> - primary->crtc = crtc;
> - cursor->crtc = crtc;
commit msg vs. patch content mismatch here ...
cheers,
Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
h
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f313b4d..3099390 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm
Hi,
> > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > explain how the guest framebuffer can be accessed then.
>
> You can check "fb_decoder.h". One thing to clarify. Its format is
> actually based on drm definition, instead of OpenGL. Sorry for
> that.
drm is fine.
Hi,
> > Yes, vGPU may have additional features, like a framebuffer area, that
> > aren't present or optional for direct assignment. Obviously we support
> > direct assignment of GPUs for some vendors already without this feature.
>
> For exposing framebuffers for spice/vnc I highly recommend a
Hi,
> But there's some work to add generic mmap support to dma-bufs, and for
> really simple case (where we don't have a gl driver to handle the dma-buf
> specially) for untiled framebuffers that would be all we need?
Not requiring gl is certainly a bonus, people might want build qemu
without o
Commit "30c964a drm/i915: Detect virtual south bridge" detects and
handles the southbridge emulated by vmware esx. Add the ich9 south
bridge emulated by 'qemu -M q35'.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
drivers/gpu/drm/i915/i915_
Hi,
> btw some questions here:
>
> for non-gl and gl rendering in Qemu, are they based on dma-buf already?
> once we can export guest framebuffer in dma-buf, is there additional work
> required or just straightforward to integrate with SPICE?
Right now we are busy integrating dma-buf support
Hi,
> btw I don't think this vblank issue would be very significant. The main
> targeted usage of GVT-g is for server virtualization/cloud, where
> a remoting protocol is required for customer to see the content through
> network.
The plan for that is to let the gpu video encoder process the g
.
Reviewed-by: Gerd Hoffmann
cheers,
Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mi, 2016-03-30 at 11:51 +0200, Daniel Vetter wrote:
> No need to confuse userspace like this.
Reviewed-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
> > Another area of extension is how to expose a framebuffer to QEMU for
> > seamless integration into a SPICE/VNC channel. For this I believe we
> > could use a new region, much like we've done to expose VGA access
> > through a vfio device file descriptor. An area within this new
> > fra
stem id to see whenever it *really* is qemu.
Reported-by: Bjørn Mork
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3ac616d..9668162 10
stem id to see whenever it *really* is qemu.
[ v2: fix subvendor tyops ]
Reported-by: Bjørn Mork
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_d
Hi,
> 0x1af4 != 0x1a4f
Good catch, new patch sent.
thanks,
Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fr, 2016-01-29 at 09:59 +0200, Jani Nikula wrote:
> On Mon, 25 Jan 2016, Gerd Hoffmann wrote:
> > The test for the qemu q35 south bridge added by commit
> > "39bfcd52 drm/i915: more virtual south bridge detection"
> > also matches on real hardware. Having th
Signed-off-by: Gerd Hoffmann
---
depends on
http://mid.gmane.org/1453739846-3549-1-git-send-email-robb...@gentoo.org
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
h bridge detection
> 39bfcd5235e07e95ad3e70eab8e0b85db181de9e is the first bad commit
> commit 39bfcd5235e07e95ad3e70eab8e0b85db181de9e
> Author: Gerd Hoffmann
> Date: Thu Nov 26 12:03:51 2015 +0100
>
> drm/i915: more virtual south bridge detection
>
> Commit "30c964a drm/i915: Detect
> +/**
> + * Ioctl to query plane info or create dma-buf
> + */
> +#define INTEL_VGPU_QUERY_DMABUF 0
> +#define INTEL_VGPU_GENERATE_DMABUF 1
This should use _IO* #defines.
> +struct intel_vgpu_dmabuf {
> + __u32 plane_id;
> + /* out */
> + __u32 fd;
> + __u32 drm_fo
Hi,
> + } else if (plane_id == INTEL_GVT_PLANE_CURSOR) {
> + c = &pipe->cursor;
> + if (c != NULL) {
> + info->start = c->base;
> + info->width = c->width;
> + info->height = c->height;
> +
Hi,
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index ae46105..285dc16 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -502,10 +502,58 @@ struct vfio_pci_hot_reset {
>
> #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE +
virt driver also doesn't really need it, dev_to_virtio works
> perfectly fine.
Reviewed-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> +struct vfio_vgpu_dmabuf_info {
> + __u32 argsz;
> + __u32 flags;
> + struct vfio_vgpu_plane_info plane_info;
> + __s32 fd;
> + __u32 pad;
> +};
Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...
I think we should have something like this:
struct vfio_vgpu
Hi,
> This patch set adds the dma-buf support for intel GVT-g.
> dma-buf is a uniform mechanism to share DMA buffers across different
> devices and sub-systems.
> dma-buf for intel GVT-g is mainly used to share the vgpu's
> framebuffer
> to other users or sub-systems so they can use the dma-buf
On Wed, 2017-05-31 at 02:29 +, Chen, Xiaoguang wrote:
> Hi Gerd,
>
> It is based on 4.12.0-rc1
Applies, good.
But then fails to build:
error: ‘struct vfio_vgpu_dmabuf_info’ has no member named ‘resv’
gvt/kvmgt.c:611:11: note: in expansion of macro ‘offsetofend’
minsz = offsetofend(struct
On Sat, 2017-05-27 at 16:38 +0800, Xiaoguang Chen wrote:
> + if (plane_id == PLANE_PRIMARY) {
Should be DRM_PLANE_TYPE_PRIMARY (likewise for the cursor).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailm
> struct vfio_vgpu_surface_info {
> __u64 start;
> __u32 width;
> __u32 height;
> __u32 stride;
> __u32 size;
> __u32 x_pos;
> __u32 y_pos;
> __u32 padding;
> /* Only used when VFIO_VGPU_SURFACE_DMABUF_* flags set */
>
Hi,
> > When i915's dma-buf's release() callback is called it will try to
> > free the gem object associated with the dma-buf if its ref count is
> > 0. But in our case the ref count is 1 so no free callback is called
> > so we can not release allocations there.
Why the ref count is one? Who h
Hi,
> > Why the ref count is one?
>
> The gem object is created by us while creating the dma-buf(the ref
> count of the gem object is initialized to 1).
> Later when user import the dma-buf the ref count of the gem object
> associate with the dma-buf will increased.
Creating the dma-buf shou
On Mon, 2017-06-05 at 13:56 +0530, Kirti Wankhede wrote:
>
> On 6/2/2017 2:08 PM, Gerd Hoffmann wrote:
> >
> > > struct vfio_vgpu_surface_info {
> > > __u64 start;
> > > __u32 width;
> > > __u32 height;
>
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
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
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
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,
> > 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 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
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
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
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
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
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 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,
> > 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
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,
> 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
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
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + * struct vfio_device_query_gfx_plane)
> + * Return: 0 on success, -errno on failure.
> + */
> +
> +struct vfio_device_gfx_plane_info {
> + __u64 start;
> + __u64 drm_format_mod;
> +
Hi,
> > +struct vfio_device_query_gfx_plane {
> > + __u32 argsz;
> > + __u32 flags;
> > + struct vfio_device_gfx_plane_info plane_info;
> > + __u32 plane_type;
> > + __s32 fd; /* dma-buf fd */
> > + __u32 plane_id;
> > +};
> > +
>
> It would be better to have comment here about what
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
Hi,
> In case when VFIO region is used to provide surface to QEMU, plane_id
> would be region index,
Then we should name it "region_index" not "plane_id".
> for example region 10 could be used for primary
> surface and region 11 could be used for cursor surface. So in that
> case,
> mdev vendo
Hi,
> Another open is, so far, our design is focused on dmabuf based gfx
> plane only. Can we go a step further to consider a general
> Buffer sharing interface? If we reference V4L2, we can see dmabuf can
> be considered as one kind of buffers, we can have more
> kinds of buffers, like mmap bu
Hi,
> +struct vfio_device_gfx_plane_info {
> + __u32 argsz;
> + __u32 flags;
> + /* in */
> + __u32 drm_plane_type; /* type of plane:
> DRM_PLANE_TYPE_* */
> + /* out */
> + __u32 drm_format; /* drm format of plane */
DRM_FORMAT_*
drm_format_mod is gone? Not ne
Hi,
> There could be only two planes, one DRM_PLANE_TYPE_PRIMARY and one
> DRM_PLANE_TYPE_CURSOR.
> Steps from gfx_update for region case would be:
> - VFIO_DEVICE_QUERY_GFX_PLANE with plane_type =
> DRM_PLANE_TYPE_PRIMARY
> - if vfio_device_gfx_plane_info.size > 0, read region for primary
> su
On Fri, 2017-07-14 at 15:45 +0530, Kirti Wankhede wrote:
>
> On 7/14/2017 3:31 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> > > In case when VFIO region is used to provide surface to QEMU,
> > > plane_id
> > > would be region index,
> >
>
Hi,
> No need of flag here. If vGPU driver is not loaded in the guest,
> there
> is no surface being managed by vGPU, in that case this size will be
> zero.
Ok, we certainly have the same situation with intel. When the guest
driver is not loaded (yet) there is no valid surface.
We should clea
On Wed, 2017-07-19 at 00:16 +, Zhang, Tina wrote:
> > -Original Message-
> > From: Gerd Hoffmann [mailto:kra...@redhat.com]
> > Sent: Monday, July 17, 2017 7:03 PM
> > To: Kirti Wankhede ; Zhang, Tina
> > ; Tian, Kevin ; linux-
> &g
Hi,
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> struct vfio_device_query_gfx_plane)
> + *
> + * Set the drm_plane_type and retrieve information about the gfx
> plane.
+ *
> + * Return: 0 on success, -errno on failure.
I think this should be more verbose, especia
Hi,
[ bringing a private discussion back to the list ]
> The dma-buf's life cycle is handled by user mode and tracked by
> kernel.
> The returned fd in struct vfio_device_query_gfx_plane can be a new
> fd or an old fd of a re-exported dma-buf. Host user mode can check
> the
> value of fd and to
Hi,
> So, there is a problem about the releasing cached dmabuf_obj. We
> cannot rely on the drm_i915_gem_object_ops.release() to release the
> cached dmabuf_obj,
> as this release operation is running in another thread, which leads
> to a racing condition and tricky to be solved without touching
e kref_{get,put} operations for the list elements.
Patch against my tree, only build-tested so far.
cheers,
Gerd>From 3e8c30a857d98d36357e8d9bb04b7ccb72264543 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Fri, 29 Sep 2017 08:59:34 +0200
Subject: [PATCH] fix locking
---
driv
On Fri, 2017-09-29 at 07:04 +, Zhang, Tina wrote:
> So, there won't be dmabuf leaking problem, as we release all the
> dmabuf_obj in the release ops when user space crashing.
>
> Can we just stop considering the way to fix the dmabuf life-cycle
> issue and try to just consider the generic way
Hi,
> + __u32 x_pos;/* horizontal position of cursor plane,
> upper left corner in pixels */
> + __u32 y_pos;/* vertical position of cursor plane,
> upper left corner in lines*/
Completely separate question: Does the host know the cursor hotspot?
cheers,
Gerd
__
Hi,
> > > Does the generic way need the close ioctl?
> >
> > I think we don't need a close ioctl anyway.
>
> Can you share your thoughts?
See other mail. I think the race can be fixed by changing the locking,
so a explicit close ioctl isn't needed.
> Do you think the fd interface is enough
Hi,
> For example, if the old reused dmabuf_obj is released just after
> query ioctl return it, the next get_fd ioctl would
> return error as the dmabuf_obj has already been closed.
My branch already grabs an extra reference when creating a new
dmabuf_obj, which will be dropped on GET_DMABUF i
Hi,
> +static struct pixel_format bdw_pixel_formats[] = {
> + {DRM_FORMAT_C8, 8, "8-bit Indexed"},
> +static struct pixel_format skl_pixel_formats[] = {
> + {DRM_FORMAT_YUYV, 16, "16-bit packed YUYV (8:8:8:8 MSB-
> V:Y2:U:Y1)"},
Broadwell and Skylake.
What is the state for newer chips
Hi,
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + *struct
> vfio_device_query_gfx_plane)
> + *
> + * Set the drm_plane_type and flags, then retrieve the gfx plane
> info.
> + *
> + * flags supported:
> + * - VFIO_GFX_PLANE_TYPE
Hi,
> > I thought we had agreed to make this behave similar to
> > VFIO_GROUP_GET_DEVICE_FD, the ioctl would take a __u32 dmabuf_id
> > and
> > return the file descriptor as the ioctl return value. Thanks,
>
> If we follow VFIO_GROUP_GET_DEVICE_FD, we would lose flags
> functionality.
> Zhi an
Hi,
> > Add a head field here? People asked @ kvm forum about multihead
> > support.
> > Even if the initial driver version doesn't support it we could add
> > a field so it
> > becomes easier to add it at some point in the future.
> >
> > Probing for available heads could be done with the PRO
Hi,
> Should we then specify the error code for "head doesn't exist" vs
> "head
> doesn't support dmabuf", with the former taking precedence? Perhaps
> -ENODEV vs -EINVAL.
NODEV for "head doesn't exist" and INVAL for "head doesn't support
dmabuf/region/..." ?
> Are the heads guaranteed to be
On Thu, Nov 09, 2017 at 05:33:56PM +0800, Tina Zhang wrote:
> v16->v17:
> 1) modify VFIO_DEVICE_GET_GFX_DMABUF interface. (Alex)
> 2) add comments for x_hot/y_hot. (Gerd)
Hmm, doesn't apply cleanly here.
Tried 4.14-rc8 + gem proxy v2 + this series.
Seems the patches depend on unmerged gvt changes.
Hi,
> struct vfio_device_gfx_plane_info lacks the head field we've been
> discussing. Thanks,
Adding multihead support turned out to not be that easy. There are
corner cases like a single framebuffer spawning both heads. Also it
would be useful to somehow hint to the guest which heads it sho
101 - 200 of 220 matches
Mail list logo
