[PATCH] drm/qxl: use qxl_num_crtc directly

2018-12-06 Thread Gerd Hoffmann
Just use qxl_num_crtc directly everywhere instead of using qdev->monitors_config->max_allowed. Drops pointless indirection and also is less confusing. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 21 + 1 file changed, 9 insertions(+), 12 del

Re: [PATCH v3 2/2] vfio: add edid support to mbochs sample driver

2018-09-27 Thread Gerd Hoffmann
> > + case MBOCHS_EDID_REGION_INDEX: > > + ext->base.argsz = sizeof(*ext); > > + ext->base.offset = MBOCHS_EDID_OFFSET; > > + ext->base.size = MBOCHS_EDID_SIZE; > > + ext->base.flags = (VFIO_REGION_INFO_FLAG_READ | > > +

[PATCH v3 2/2] vfio: add edid support to mbochs sample driver

2018-09-21 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann --- samples/vfio-mdev/mbochs.c | 136 ++--- 1 file changed, 117 insertions(+), 19 deletions(-) diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c index 2535c3677c..ca7960adf5 100644 --- a/samples/vfio-mdev

[PATCH v3 1/2] vfio: add edid api for display (vgpu) devices.

2018-09-21 Thread Gerd Hoffmann
This allows to set EDID monitor information for the vgpu display, for a more flexible display configuration, using a special vfio region. Check the comment describing struct vfio_region_gfx_edid for more details. Signed-off-by: Gerd Hoffmann --- include/uapi/linux/vfio.h | 50

Re: [PATCH v2 1/2] vfio: add edid api for display (vgpu) devices.

2018-09-20 Thread Gerd Hoffmann
On Wed, Sep 19, 2018 at 01:52:19PM -0600, Alex Williamson wrote: > On Tue, 18 Sep 2018 15:38:12 +0200 > Gerd Hoffmann wrote: > > No empty commit logs please. There must be something to say about the > goal or motivation beyond the subject. > > > Sign

Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.

2018-09-19 Thread Gerd Hoffmann
> >> Once display manger is kicked off for example (sudo systemctl start > >> lightdm.service) and > >> resource id 3 gets created from user space down, it still gives a blank > >> black screen. > > > > Hmm. I'd suspect there is simply a code path missing. Can you send the > > patch you have?

[PATCH v2 1/2] vfio: add edid api for display (vgpu) devices.

2018-09-18 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann --- include/uapi/linux/vfio.h | 39 +++ 1 file changed, 39 insertions(+) diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index 1aa7b82e81..78e5a37d83 100644 --- a/include/uapi/linux/vfio.h +++ b/include/uapi

[PATCH v2 2/2] vfio: add edid support to mbochs sample driver

2018-09-18 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann --- samples/vfio-mdev/mbochs.c | 115 + 1 file changed, 96 insertions(+), 19 deletions(-) diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c index 2535c3677c..4e72d36ff3 100644 --- a/samples/vfio-mdev

Re: [PATCH 1/2] vfio: add edid api for display (vgpu) devices.

2018-09-17 Thread Gerd Hoffmann
On Mon, Sep 17, 2018 at 05:15:50PM +0800, Zhenyu Wang wrote: > On 2018.09.17 10:50:33 +0200, Gerd Hoffmann wrote: > > > > +#define VFIO_DEVICE_INFO_CAP_EDID 1 > > > > + > > > > +struct vfio_device_info_edid_cap { > > > > + struct

Re: [PATCH 1/2] vfio: add edid api for display (vgpu) devices.

2018-09-17 Thread Gerd Hoffmann
> > +#define VFIO_DEVICE_INFO_CAP_EDID 1 > > + > > +struct vfio_device_info_edid_cap { > > + struct vfio_info_cap_header header; > > + __u32 max_x; /* Max display height (zero == no limit) */ > > + __u32 max_y; /* Max display height (zero == no limit) */ > > +}; > > As current

Re: [PATCH 1/2] vfio: add edid api for display (vgpu) devices.

2018-09-14 Thread Gerd Hoffmann
that look like? If it is ok I'll go continue with that next week (more verbose docs, update qemu code and test, ...) cheers, Gerd >From 818f2ea4dd756d28908e58a32a2fdd0d197a28da Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Thu, 6 Sep 2018 16:17:17 +0200 Subject: [PATCH] vfio: add edid

[PATCH 2/2] vfio: add edid support to mbochs sample driver

2018-09-12 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann --- samples/vfio-mdev/mbochs.c | 54 -- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c index 2535c3677c..6331871ff5 100644 --- a/samples/vfio-mdev

[PATCH 1/2] vfio: add edid api for display (vgpu) devices.

2018-09-12 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann --- include/uapi/linux/vfio.h | 38 ++ 1 file changed, 38 insertions(+) diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index 1aa7b82e81..38b591e909 100644 --- a/include/uapi/linux/vfio.h +++ b/include/uapi

[PATCH 03/10] udmabuf: use pgoff_t for pagecount

2018-09-11 Thread Gerd Hoffmann
Reported-by: Laurent Pinchart Signed-off-by: Gerd Hoffmann --- drivers/dma-buf/udmabuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 19bd918209..ec22f203b5 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers

Re: [PATCH v7] Add udmabuf misc device

2018-09-10 Thread Gerd Hoffmann
On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote: > Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann: > > > > By default qemu doesn't use memfd for backing storage, you have to > > explicitly configure qemu that way (see qemu commit log o

Re: [PATCH v7] Add udmabuf misc device

2018-09-10 Thread Gerd Hoffmann
On Mon, Sep 10, 2018 at 11:18:38AM +0200, Gert Wollny wrote: > Am Montag, den 10.09.2018, 10:37 +0200 schrieb Gerd Hoffmann: > ... > > > > The other question is of course, why did dma_buf_export fail for me > > > ... > > > > What exactly did you try? >

Re: [PATCH v7] Add udmabuf misc device

2018-09-10 Thread Gerd Hoffmann
Hi, > > + fput(memfd); > > + } > > + memfd = NULL; > Now memfd is NULL > > + buf = dma_buf_export(_info); > > + if (IS_ERR(buf)) { > > + ret = PTR_ERR(buf); > > + goto err_put_pages; > Assume an error occured > > +err_put_pages: > > + while (pgbuf >

[PATCH] drm: refuse ADDFB2 ioctl for broken bigendian drivers

2018-09-06 Thread Gerd Hoffmann
block it to make userspace fallback to ADDFB. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/drm_ioctl.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index ea10e9a26a..08e48bda23 100644

[PATCH v2 6/6] drm/virtio: fix DRM_FORMAT_* handling

2018-09-05 Thread Gerd Hoffmann
and ADDFB2 ioctls work correctly in the virtio-gpu.ko driver on big endian machines. Without the patch only ADDFB (which still seems to be used by the majority of userspace) works correctly. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++ drivers/gpu/drm/virtio

Re: [PATCH v6] Add udmabuf misc device

2018-07-04 Thread Gerd Hoffmann
Hi, > > Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists > > listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc. > > Yeah, maintainers entry with you as maintainer plus dri-devel as mailing > list plus drm-misc as repo would be good. Just grep for drm-misc.git

Re: [PATCH v6] Add udmabuf misc device

2018-07-04 Thread Gerd Hoffmann
On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: > On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: > > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: > > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote: > > > > A driver to le

Re: [PATCH 2/2] sample/mdev/mbochs: add mbochs_kunmap_dmabuf

2018-06-26 Thread Gerd Hoffmann
> > .map = mbochs_kmap_dmabuf, > > + .unmap= mbochs_kunmap_dmabuf, > > .mmap = mbochs_mmap_dmabuf, > > }; > > > > Is this a fix for v4.18? Yes. > AFAICT, the kmap_atomic removal is only in > next, not yet upstream and hopefully includes this

[PATCH v3] Add udmabuf misc device

2018-05-25 Thread Gerd Hoffmann
Vizoso <tomeu.viz...@collabora.com> Cc: Daniel Vetter <dan...@ffwll.ch> Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- include/uapi/linux/udmabuf.h | 19 ++ drivers/dma-buf/udmabuf.c | 240 ++ tools/testing/s

Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t

2018-05-14 Thread Gerd Hoffmann
Hi, > > So my expectation that a backmerge happens anyway after -rc1/2 is in > > line with reality, it is just to be delayed this time. I'll stay > > tuned ;) > > Is this patch already merged in drm-misc-next tree ? Pushed now. cheers, Gerd

[PATCH v2 1/3] sample: vfio mdev display - host device

2018-04-24 Thread Gerd Hoffmann
Simple framebuffer display, demo-ing the vfio region display interface (VFIO_GFX_PLANE_TYPE_REGION). Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- samples/vfio-mdev/mdpy-defs.h | 22 ++ samples/vfio-mdev/mdpy.c | 807 ++ samples/K

[PATCH v2 2/3] sample: vfio mdev display - guest driver

2018-04-24 Thread Gerd Hoffmann
Guest fbdev driver for CONFIG_SAMPLE_VFIO_MDEV_MDPY. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- samples/vfio-mdev/mdpy-fb.c | 232 samples/Kconfig | 9 ++ samples/vfio-mdev/Makefile | 1 + 3 files changed, 242 inse

[PATCH v2 3/3] sample: vfio bochs vbe display (host device for bochs-drm)

2018-04-24 Thread Gerd Hoffmann
Display device, demo-ing the vfio dmabuf display interface (VFIO_GFX_PLANE_TYPE_DMABUF). Compatible enough to qemu stdvga that bochs-drm.ko can be used as guest driver. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- samples/vfio-mdev/mbochs.c

Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t

2018-04-24 Thread Gerd Hoffmann
On Tue, Apr 24, 2018 at 02:11:51PM +0200, Daniel Vetter wrote: > On Mon, Apr 23, 2018 at 12:49:24PM +0200, Gerd Hoffmann wrote: > > On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote: > > > Use new return type vm_fault_t for fault handler. For > > > no

Re: [PATCH 1/3] sample: vfio mdev display - host device

2018-04-24 Thread Gerd Hoffmann
Hi, > > +/* pci ids */ > > +#define MDPY_PCI_VENDOR_ID 0x1b36 /* redhat */ > > +#define MDPY_PCI_DEVICE_ID 0x00f0 > > I don't see this on pci-ids, so I assume we're just squatting on an > ID. How do we do that without risking that we don't interfere with > some future user? Are we relying on

Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t

2018-04-23 Thread Gerd Hoffmann
On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. >

Re: [PATCH] drm/virtio: fix vq wait_event condition

2018-04-20 Thread Gerd Hoffmann
On Tue, Apr 03, 2018 at 11:59:04AM +0200, Gerd Hoffmann wrote: > Wait until we have enough space in the virt queue to actually queue up > our request. Avoids the guest spinning in case we have a non-zero > amount of free entries but not enough for the request. Ping airlied, can you plea

[PATCH v2 4/4] qxl: drop dummy functions

2018-04-20 Thread Gerd Hoffmann
These days drm core checks function pointers everywhere before calling them. So we can drop a bunch of dummy functions now. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 50 --- 1 file changed, 50 deletions(-)

[PATCH v2 2/4] qxl: move qxl_send_monitors_config()

2018-04-20 Thread Gerd Hoffmann
Needed to avoid a forward declaration in a followup patch. Pure code move, no functional change. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 47 +++ 1 file changed, 23 insertions(+), 24 deletions(-) diff

[PATCH v2 3/4] qxl: hook monitors_config updates into crtc, not encoder.

2018-04-20 Thread Gerd Hoffmann
callbacks. Remove monitors_config updates from all other places. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1544322 Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_cmd.c | 2 + drivers/gpu/drm/qxl/qxl_display.c

[PATCH v2 1/4] qxl: remove qxl_io_log()

2018-04-20 Thread Gerd Hoffmann
qxl_io_log() sends messages over to the host (qemu) for logging. Remove the function and all callers, we can just use standard DRM_DEBUG calls (and if needed a serial console). Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 3 --- drivers/gpu/d

[PATCH 2/2] qxl: keep separate release_bo pointer

2018-04-17 Thread Gerd Hoffmann
qxl expects that list_first_entry(release->bos) returns the first element qxl added to the list. ttm_eu_reserve_buffers() may reorder the list though. Add a release_bo field to struct qxl_release and use that instead. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gp

[PATCH 1/2] qxl: fix qxl_release_{map,unmap}

2018-04-17 Thread Gerd Hoffmann
s/PAGE_SIZE/PAGE_MASK/ Luckily release_offset is never larger than PAGE_SIZE, so the bug has no bad side effects and managed to stay unnoticed for years that way ... Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_ioctl.c | 4 ++-- drivers/gpu/d

Re: [RfC PATCH] Add udmabuf misc device

2018-04-10 Thread Gerd Hoffmann
Hi, > Generally we try to cache mappings as much as possible. And wrt finding a > slot: Create a sufficiently sized BAR on the virgl device, just for that? Well. virtio has no concept of "bars" ... The most common virtio transport layer happens to be pci, which actually has bars. But we

[PATCH 1/3] sample: vfio mdev display - host device

2018-04-09 Thread Gerd Hoffmann
Simple framebuffer display, demo-ing the vfio region display interface (VFIO_GFX_PLANE_TYPE_REGION). Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- samples/vfio-mdev/mdpy-defs.h | 19 + samples/vfio-mdev/mdpy.c | 791 ++ samples/K

[PATCH 2/3] sample: vfio mdev display - guest driver

2018-04-09 Thread Gerd Hoffmann
Guest fbdev driver for CONFIG_SAMPLE_VFIO_MDEV_MDPY. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- samples/vfio-mdev/mdpy-fb.c | 232 samples/Kconfig | 9 ++ samples/vfio-mdev/Makefile | 1 + 3 files changed, 242 inse

[PATCH 3/3] sample: vfio bochs vbe display (host device for bochs-drm)

2018-04-09 Thread Gerd Hoffmann
Display device, demo-ing the vfio dmabuf display interface (VFIO_GFX_PLANE_TYPE_DMABUF). Compatible enough to qemu stdvga that bochs-drm.ko can be used as guest driver. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- samples/vfio-mdev/mbochs.c

Re: [RfC PATCH] Add udmabuf misc device

2018-04-06 Thread Gerd Hoffmann
Hi, > > I fail to see any common ground for xen-zcopy and udmabuf ... > Does the above mean you can assume that xen-zcopy and udmabuf > can co-exist as two different solutions? Well, udmabuf route isn't fully clear yet, but yes. See also gvt (intel vgpu), where the hypervisor interface is

Re: [RfC PATCH] Add udmabuf misc device

2018-04-06 Thread Gerd Hoffmann
On Fri, Apr 06, 2018 at 10:52:21AM +0100, Daniel Stone wrote: > Hi Gerd, > > On 14 March 2018 at 08:03, Gerd Hoffmann <kra...@redhat.com> wrote: > >> Either mlock account (because it's mlocked defacto), and get_user_pages > >> won't do that for you. > >>

Re: [PATCH v2] Add udmabuf misc device

2018-04-06 Thread Gerd Hoffmann
Hi, > The pages backing a DMA-buf are not allowed to move (at least not without a > patch set I'm currently working on), but for certain MM operations to work > correctly you must be able to modify the page tables entries and move the > pages backing them around. > > For example try to use

Re: [RfC PATCH] Add udmabuf misc device

2018-04-06 Thread Gerd Hoffmann
Hi, > > * The general interface should be able to express sharing from any > > guest:guest, not just guest:host. Arbitrary G:G sharing might be > > something some hypervisors simply aren't able to support, but the > > userspace API itself shouldn't make assumptions or restrict

[PATCH] drm/virtio: fix vq wait_event condition

2018-04-03 Thread Gerd Hoffmann
Wait until we have enough space in the virt queue to actually queue up our request. Avoids the guest spinning in case we have a non-zero amount of free entries but not enough for the request. Cc: sta...@vger.kernel.org Reported-by: Alain Magloire <amaglo...@blackberry.com> Signed-off-by

[PATCH v2] Add udmabuf misc device

2018-03-16 Thread Gerd Hoffmann
= MISC_DYNAMIC_MINOR, + .name = "udmabuf", + .fops = _fops, +}; + +static int __init udmabuf_dev_init(void) +{ + return misc_register(_misc); +} + +static void __exit udmabuf_dev_exit(void) +{ + misc_deregister(_misc); +} + +module_init(udmabuf_dev_

Re: [RfC PATCH] Add udmabuf misc device

2018-03-14 Thread Gerd Hoffmann
arg for get_user_pages_fast and figured we might support that, but if iommus can't handle that anyway it's pointless indeed. > > Cc: David Airlie <airl...@linux.ie> > > Cc: Tomeu Vizoso <tomeu.viz...@collabora.com> > > Signed-off-by: Gerd Hoffmann <kra...@re

[RfC PATCH] Add udmabuf misc device

2018-03-13 Thread Gerd Hoffmann
irl...@linux.ie> Cc: Tomeu Vizoso <tomeu.viz...@collabora.com> Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- include/uapi/linux/udmabuf.h | 21 drivers/dma-buf/udmabuf.c| 250 +++ drivers/dma-buf/Kconfig | 7 ++ driver

Re: [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

2018-03-01 Thread Gerd Hoffmann
Hi, > 1. Possible security issues - VirtIO devices are PCI bus masters, thus > allowing real device (running, for example, in untrusted driver domain) > to get control over guest's memory by writing to its memory > > 2. VirtIO currently uses GFNs written into the shared ring, without Xen >

Re: [PATCH 0/7] drm/virtio: Checkpatch cleanup for virtio

2018-02-26 Thread Gerd Hoffmann
On Thu, Feb 22, 2018 at 08:59:33PM -0300, Rodrigo Siqueira wrote: > This patchset fixes warnings and errors found by checkpatch.pl in the > drm/virtio: Added to drm-qemu queue, will land in drm-misc soon. thanks, Gerd

[PATCH 2/4] qxl: move qxl_send_monitors_config()

2018-02-16 Thread Gerd Hoffmann
Needed to avoid a forward declaration in a followup patch. Pure code move, no functional change. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 47 +++ 1 file changed, 23 insertions(+), 24 deletions(-) diff

[PATCH 1/4] qxl: remove qxl_io_log()

2018-02-16 Thread Gerd Hoffmann
qxl_io_log() sends messages over to the host (qemu) for logging. Remove the function and all callers, we can just use standard DRM_DEBUG calls (and if needed a serial console). Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 3 --- drivers/gpu/d

[PATCH 4/4] qxl: drop dummy functions

2018-02-16 Thread Gerd Hoffmann
These days drm core checks function pointers everywhere before calling them. So we can drop a bunch of dummy functions now. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 50 --- 1 file changed, 50 deletions(-)

[PATCH 3/4] qxl: hook monitors_config updates into crtc, not encoder.

2018-02-16 Thread Gerd Hoffmann
callbacks. Remove monitors_config updates from all other places. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1544322 Signed-off-by: Gerd Hoffmann <kra...@redhat.com> --- drivers/gpu/drm/qxl/qxl_cmd.c | 2 + drivers/gpu/drm/qxl/qxl_display.c

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-16 Thread Gerd Hoffmann
> > Yes. > > Would it make sense for virtio-gpu to map buffers to the guest via PCI BARs? > So we can use a single drm driver for both 2d and 3d. Should be doable. I'm wondering two things though: (1) Will shmem actually help avoiding a copy? virtio-gpu with virgl will (even if the guest

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Gerd Hoffmann
> > I was more thinking about a struct containing enough info to allow the > > proxy on the host side find the buffer, something like: > > > > struct { > >enum type { stdvga, virtio-cpu, ... } > >pcislot device; > >union { > > int stdvga_pcibar_offset; > >

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Gerd Hoffmann
On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote: > On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: > >Hi, > > > > > can we reach agreement on whether vsock should be involved in this? > > > > I think the best approach would be to have gues

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Gerd Hoffmann
Hi, > can we reach agreement on whether vsock should be involved in this? I think the best approach would be to have guest proxy and host proxy use vsock for the wayland protocol. Use a wayland protocol extension to reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two proxies

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-12 Thread Gerd Hoffmann
Hi, > >(a) software rendering: client allocates shared memory buffer, renders > >into it, then passes a file handle for that shmem block together > >with some meta data (size, format, ...) to the wayland server. > > > >(b) gpu rendering: client opens a render node,

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-06 Thread Gerd Hoffmann
Hi, > > Hmm? I'm assuming the wayland client (in the guest) talks to the > > wayland proxy, using the wayland protocol, like it would talk to a > > wayland display server. Buffers must be passed from client to > > server/proxy somehow, probably using fd passing, so where is the > > problem? >

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-05 Thread Gerd Hoffmann
On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote: > On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: > >Hi, > > > > > > Why not use virtio-vsock to run the wayland protocol? I don't like > > > > the idea to duplicate something with very siml

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-05 Thread Gerd Hoffmann
Hi, > > Why not use virtio-vsock to run the wayland protocol? I don't like > > the idea to duplicate something with very simliar functionality in > > virtio-gpu. > > The reason for abandoning that approach was the type of objects that > could be shared via virtio-vsock would be extremely

Re: [PATCH v3 1/2] drm/virtio: Add window server support

2018-02-01 Thread Gerd Hoffmann
Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the

Re: [PATCH v18 0/6] drm/i915/gvt: Dma-buf support for GVT-g

2017-11-16 Thread Gerd Hoffmann
> > > This patch set can be tried with the following example: > > > git://git.kraxel.org/qemu branch: work/intel-vgpu > > > > > > > Tested-by: Gerd Hoffmann <kra...@redhat.com> > > Hi Gerd, > > Can you share the xml snippets require

Re: [PATCH v18 0/6] drm/i915/gvt: Dma-buf support for GVT-g

2017-11-15 Thread Gerd Hoffmann
g/qemu branch: work/intel-vgpu > > A topic branch with the latest patch set is: > https://github.com/intel/gvt-linux.git branch: topic/dmabuf Tested-by: Gerd Hoffmann <kra...@redhat.com>

Re: [PATCH v18 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-15 Thread Gerd Hoffmann
sources according to the new exposed buffer > or just re-use the existing resource related to the old buffer. Reviewed-by: Gerd Hoffmann <kra...@redhat.com>

Re: [PATCH v17 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-09 Thread Gerd Hoffmann
On Thu, Nov 09, 2017 at 01:54:57PM -0700, Alex Williamson wrote: > On Thu, 9 Nov 2017 19:35:14 +0100 > Gerd Hoffmann <kra...@redhat.com> wrote: > > > Hi, > > > > > struct vfio_device_gfx_plane_info lacks the head field we've been > > > discussing.

Re: [PATCH v17 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-09 Thread Gerd Hoffmann
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

Re: [PATCH v17 0/6] drm/i915/gvt: Dma-buf support for GVT-g

2017-11-09 Thread Gerd Hoffmann
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

Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-07 Thread Gerd Hoffmann
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

Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-06 Thread Gerd Hoffmann
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

Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-06 Thread Gerd Hoffmann
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: > + * -

Re: [PATCH v16 1/6] drm/i915/gvt: Add framebuffer decoder support

2017-11-06 Thread Gerd Hoffmann
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

Re: [PATCH v15 5/7] vfio: ABI for mdev display dma-buf operation

2017-10-11 Thread Gerd Hoffmann
Hi, > No, the parameter wouldn't be a char, you'd use an __u32 for the > dmabuf_id.  I'm just referencing the structure of the GET_DEVICE_FD > as > an ioctl which returns an fd through the return value and takes a > single parameter.  I don't mean to imply matching the type of that > parameter.

Re: [PATCH v15 5/7] vfio: ABI for mdev display dma-buf operation

2017-10-10 Thread Gerd Hoffmann
acked 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 see if it needs to create new resource according > to > the new fd or just use the existed resourc

Re: [PATCH v15 0/7] drm/i915/gvt: Dma-buf support for GVT-g

2017-10-10 Thread Gerd Hoffmann
gt; With the fd of this dma-buf, userspace can directly handle this > buffer. Tested-by: Gerd Hoffmann <kra...@redhat.com> cheers, Gerd

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

2017-09-12 Thread Gerd Hoffmann
On Tue, 2017-09-12 at 17:09 +0300, Dan Carpenter wrote: > On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote: > > That said, I'm not sure how useful the information is - perhaps > > it's > > better to drop it all together? > > Or a WARN_ONCE(). It's userspace calling into the driver

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

2017-07-19 Thread Gerd Hoffmann
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 <kwankh...@nvidia.com>; Zhang, Tina > > <tina.zh...@intel.

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

2017-07-17 Thread Gerd Hoffmann
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

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

2017-07-14 Thread Gerd Hoffmann
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, > > >

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

2017-07-14 Thread Gerd Hoffmann
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 >

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

2017-07-14 Thread Gerd Hoffmann
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

Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-07-14 Thread Gerd Hoffmann
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

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

2017-07-11 Thread Gerd Hoffmann
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

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

2017-07-11 Thread Gerd Hoffmann
> +/** > + * 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; > +

Re: [PATCH] drm: ttm: virtio-gpu: dma-buf: Constify ttm_place structures.

2017-07-03 Thread Gerd Hoffmann
On Sun, 2017-07-02 at 13:11 +0530, Arvind Yadav wrote: > ttm_place are not supposed to change at runtime. All functions > working with ttm_place provided by work > with const ttm_place. So mark the non-const structs as const. > > File size before: >    text    data bss dec hex

Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

2017-07-03 Thread Gerd Hoffmann
Hi, > Hopefully Gerd has experience using bochs_drm with other non-x86 > systems > and can comment further. Just pushed to drm-misc-next, fix is correct. bochs video memory is a pci bar, and the framebuffer is stored there. Using sys instead of cfb is probably a leftover from cirrus, where

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-29 Thread Gerd Hoffmann
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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-27 Thread Gerd Hoffmann
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 >

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-26 Thread Gerd Hoffmann
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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-26 Thread Gerd Hoffmann
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 >

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-23 Thread Gerd Hoffmann
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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-23 Thread Gerd Hoffmann
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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-22 Thread Gerd Hoffmann
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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-21 Thread Gerd Hoffmann
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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-21 Thread Gerd Hoffmann
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 */ >

Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-21 Thread Gerd Hoffmann
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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-20 Thread Gerd Hoffmann
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; >

Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

2017-06-20 Thread Gerd Hoffmann
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

  1   2   3   4   5   6   7   >