From patchwork Fri Sep 7 14:05:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerd Hoffmann X-Patchwork-Id: 10592229 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 18EB4920 for ; Fri, 7 Sep 2018 14:05:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 09ADF2B451 for ; Fri, 7 Sep 2018 14:05:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 07DC22B42B; Fri, 7 Sep 2018 14:05:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AA9822B44A for ; Fri, 7 Sep 2018 14:05:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727881AbeIGSqZ (ORCPT ); Fri, 7 Sep 2018 14:46:25 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:36256 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727328AbeIGSqZ (ORCPT ); Fri, 7 Sep 2018 14:46:25 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DBF5A8576D; Fri, 7 Sep 2018 14:05:17 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-66.ams2.redhat.com [10.36.116.66]) by smtp.corp.redhat.com (Postfix) with ESMTP id BDF7F2027EA0; Fri, 7 Sep 2018 14:05:15 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 2552F4F268; Fri, 7 Sep 2018 16:05:15 +0200 (CEST) Date: Fri, 7 Sep 2018 16:05:15 +0200 From: Gerd Hoffmann To: intel-gvt-dev@lists.freedesktop.org, kvm@vger.kernel.org, Kirti Wankhede , Alex Williamson Subject: RfC: vfio: add vgpu edid support? Message-ID: <20180907140515.3i234v5a4ikrq6ob@sirius.home.kraxel.org> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 07 Sep 2018 14:05:17 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 07 Sep 2018 14:05:17 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'kraxel@redhat.com' RCPT:'' Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, I consider adding EDID support to qemu, for display configuration. qemu patches are here: https://git.kraxel.org/cgit/qemu/log/?h=sirius/edid linux kernel patches are here: https://git.kraxel.org/cgit/linux/log/?h=edid Current (experimental) patches have support for the stdvga and virtio-vga. I think it would be quite useful for vgpu too. Unlike emulated devices vgpu's do not have a paravirtual display configuration path, because the standard way to configure the display is to simply read the edid from the monitor. Intel has two hard-coded edid blobs for that (depending on vgpu type). Not sure how nvidia handles this, but probably simliar. With qemu passing a edid blob for the virtual display instead of using the hardcoded blob we could make the display configuration much more flexible. Ideally qemu would also be able to update the edid blob at any time, and the vgpu will notify the guest about it (probably by emulating a monitor hotplug event). The guest can react on qemu window resizing then and adapt automatically, simliar to how it works with qxl and virtio-gpu. The guest and the vgpu should be able to handle "odd" non-standard display resolutions like this (coming from random window resizing): Detailed mode: Clock 106.620 MHz, 477 mm x 330 mm 1212 1515 1551 1636 hborder 0 840 844 848 869 vborder 0 -hsync -vsync VertFreq: 74 Hz, HorFreq: 65171 Hz RfC patch for the vfio interface is below. Comments? cheers, Gerd =================== cut here =================== From 556299e8c6280b1c4061fdae15491a013c22be98 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Thu, 6 Sep 2018 16:17:17 +0200 Subject: [PATCH] [RfC] vfio: edid interface Signed-off-by: Gerd Hoffmann --- include/uapi/linux/vfio.h | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index 1aa7b82e81..9ac7dfb7c1 100644 --- a/include/uapi/linux/vfio.h +++ b/include/uapi/linux/vfio.h @@ -602,6 +602,48 @@ struct vfio_device_ioeventfd { #define VFIO_DEVICE_IOEVENTFD _IO(VFIO_TYPE, VFIO_BASE + 16) +/** + * VFIO_DEVICE_GFX_EDID_CAPS - _IOW(VFIO_TYPE, VFIO_BASE + 17, + * struct vfio_device_gfx_edid_caps) + * + * Get edid capabilities. + * + * Drivers must support either none or both GFX_EDID ioctls, + * so the CAPS ioctl can also be used to probe for edid support. + * + * max_xres, max_yres - maximum display resolution supported. + * value "0" means no restriction. + * + */ +struct vfio_device_gfx_edid_caps { + __u32 argsz; + __u32 flags; + /* out */ + __u32 max_xres; + __u32 max_yres; +}; + +#define VFIO_DEVICE_GFX_EDID_CAPS _IO(VFIO_TYPE, VFIO_BASE + 17) + +/** + * VFIO_DEVICE_GFX_EDID_SET - _IOW(VFIO_TYPE, VFIO_BASE + 18, + * struct vfio_device_gfx_edid_set) + * + * Set edid blob. + * + * Should trigger monitor hotplug emulation, to notifiy the guest os + * that the edid has changed. + * + */ +struct vfio_device_gfx_edid_set { + __u32 argsz; + __u32 flags; + /* in */ + __u8 edid[256]; +}; + +#define VFIO_DEVICE_GFX_EDID_SET _IO(VFIO_TYPE, VFIO_BASE + 18) + /* -------- API for Type1 VFIO IOMMU -------- */ /**