Skip to contentSkip to conversation

vfio: add display support

PATCH Superseded Gerd Hoffmann 5 participants 27 messages Feb 19, 2018 – Feb 26, 2018

v4 of 8 Superseded Latest is v8 →

lore
Share & tools
lore
#0 lore raw

v4 cover vfio: add display support

This series adds support for a vgpu display to the qemu vfio code. For now only regions are supported, dmabufs will follow later.

This version adds a patch to allow devices disable hotplugging, which will be used by vfio display support. Also fixed issues Alex found in review.

cheers,
Gerd

Gerd Hoffmann (7):
linux-headers: update to 4.16-rc1
standard-headers: add drm/drm_fourcc.h
ui/pixman: add qemu_drm_format_to_pixman()
qdev: add hotpluggable to DeviceState
vfio/common: cleanup in vfio_region_finalize
vfio/display: core & wireup
vfio/display: adding region support

 hw/vfio/pci.h                                      |   4 +
 include/hw/qdev-core.h                             |   1 +
 include/hw/vfio/vfio-common.h                      |   8 +
 include/standard-headers/drm/drm_fourcc.h          | 411 +++++++++++++++++++++
 include/standard-headers/linux/input-event-codes.h |   1 +
 include/standard-headers/linux/input.h             |  11 +
 include/standard-headers/linux/pci_regs.h          |  30 +-
 include/standard-headers/linux/virtio_net.h        |  13 +
 include/ui/qemu-pixman.h                           |   5 +
 linux-headers/asm-powerpc/kvm.h                    |   2 +
 linux-headers/asm-powerpc/unistd.h                 |   3 +
 linux-headers/asm-s390/unistd.h                    | 401 +-------------------
 linux-headers/asm-s390/unistd_32.h                 | 364 ++++++++++++++++++
 linux-headers/asm-s390/unistd_64.h                 | 331 +++++++++++++++++
 linux-headers/asm-x86/kvm_para.h                   |   4 +
 linux-headers/linux/kvm.h                          |  90 +++++
 linux-headers/linux/psci.h                         |   3 +
 linux-headers/linux/vfio.h                         |  72 ++++
 hw/core/qdev.c                                     |   5 +-
 hw/vfio/common.c                                   |   7 +
 hw/vfio/display.c                                  | 152 ++++++++
 hw/vfio/pci.c                                      |   9 +
 ui/qemu-pixman.c                                   |  22 ++
 hw/vfio/Makefile.objs                              |   2 +-
 scripts/update-linux-headers.sh                    |   7 +
 25 files changed, 1545 insertions(+), 413 deletions(-)
 create mode 100644 include/standard-headers/drm/drm_fourcc.h
 create mode 100644 linux-headers/asm-s390/unistd_32.h
 create mode 100644 linux-headers/asm-s390/unistd_64.h
 create mode 100644 hw/vfio/display.c
Signature · 1 line
2.9.3
#1 lore raw

PATCH v4 1/7 linux-headers: update to 4.16-rc1

s390 has splitted syscall numbers into unistd_{32,64}.h files, so update scripts/update-linux-headers.sh accordingly.

Also add a rewrite from __BITS_PER_LONG to HOST_LONG_BITS for linux/input.h

---
 include/standard-headers/linux/input-event-codes.h |   1 +
 include/standard-headers/linux/input.h             |  11 +
 include/standard-headers/linux/pci_regs.h          |  30 +-
 include/standard-headers/linux/virtio_net.h        |  13 +
 linux-headers/asm-powerpc/kvm.h                    |   2 +
 linux-headers/asm-powerpc/unistd.h                 |   3 +
 linux-headers/asm-s390/unistd.h                    | 401 +--------------------
 linux-headers/asm-s390/unistd_32.h                 | 364 +++++++++++++++++++
 linux-headers/asm-s390/unistd_64.h                 | 331 +++++++++++++++++
 linux-headers/asm-x86/kvm_para.h                   |   4 +
 linux-headers/linux/kvm.h                          |  90 +++++
 linux-headers/linux/psci.h                         |   3 +
 linux-headers/linux/vfio.h                         |  72 ++++
 scripts/update-linux-headers.sh                    |   3 +
 14 files changed, 918 insertions(+), 410 deletions(-)
 create mode 100644 linux-headers/asm-s390/unistd_32.h
 create mode 100644 linux-headers/asm-s390/unistd_64.h
include/standard-headers/linux/input-event-codes.h +1 -0
index 79841b543f..9e6a8ba4ce 100644
@@ -594,6 +594,7 @@
 #define BTN_DPAD_RIGHT		0x223
 
 #define KEY_ALS_TOGGLE		0x230	/* Ambient light sensor */
+#define KEY_ROTATE_LOCK_TOGGLE	0x231	/* Display rotation lock */
 
 #define KEY_BUTTONCONFIG		0x240	/* AL Button Configuration */
 #define KEY_TASKMANAGER		0x241	/* AL Task/Project Manager */
include/standard-headers/linux/input.h +11 -0
index bc3e6d3d5b..939b62775c 100644
@@ -18,10 +18,21 @@
 
 /*
  * The event structure itself
+ * Note that __USE_TIME_BITS64 is defined by libc based on
+ * application's request to use 64 bit time_t.
  */
 
 struct input_event {
+#if (HOST_LONG_BITS != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL)
 	struct timeval time;
+#define input_event_sec time.tv_sec
+#define input_event_usec time.tv_usec
+#else
+	__kernel_ulong_t __sec;
+	__kernel_ulong_t __usec;
+#define input_event_sec  __sec
+#define input_event_usec __usec
+#endif
 	uint16_t type;
 	uint16_t code;
 	int32_t value;
include/standard-headers/linux/pci_regs.h +18 -12
index 70c2b2ade0..0c79eac5e9 100644
@@ -622,15 +622,19 @@
  * safely.
  */
 #define PCI_EXP_DEVCAP2		36	/* Device Capabilities 2 */
+#define  PCI_EXP_DEVCAP2_COMP_TMOUT_DIS	0x00000010 /* Completion Timeout Disable supported */
 #define  PCI_EXP_DEVCAP2_ARI		0x00000020 /* Alternative Routing-ID */
 #define  PCI_EXP_DEVCAP2_ATOMIC_ROUTE	0x00000040 /* Atomic Op routing */
-#define PCI_EXP_DEVCAP2_ATOMIC_COMP64	0x00000100 /* Atomic 64-bit compare */
+#define  PCI_EXP_DEVCAP2_ATOMIC_COMP32	0x00000080 /* 32b AtomicOp completion */
+#define  PCI_EXP_DEVCAP2_ATOMIC_COMP64	0x00000100 /* 64b AtomicOp completion */
+#define  PCI_EXP_DEVCAP2_ATOMIC_COMP128	0x00000200 /* 128b AtomicOp completion */
 #define  PCI_EXP_DEVCAP2_LTR		0x00000800 /* Latency tolerance reporting */
 #define  PCI_EXP_DEVCAP2_OBFF_MASK	0x000c0000 /* OBFF support mechanism */
 #define  PCI_EXP_DEVCAP2_OBFF_MSG	0x00040000 /* New message signaling */
 #define  PCI_EXP_DEVCAP2_OBFF_WAKE	0x00080000 /* Re-use WAKE# for OBFF */
 #define PCI_EXP_DEVCTL2		40	/* Device Control 2 */
 #define  PCI_EXP_DEVCTL2_COMP_TIMEOUT	0x000f	/* Completion Timeout Value */
+#define  PCI_EXP_DEVCTL2_COMP_TMOUT_DIS	0x0010	/* Completion Timeout Disable */
 #define  PCI_EXP_DEVCTL2_ARI		0x0020	/* Alternative Routing-ID */
 #define PCI_EXP_DEVCTL2_ATOMIC_REQ	0x0040	/* Set Atomic requests */
 #define PCI_EXP_DEVCTL2_ATOMIC_EGRESS_BLOCK 0x0080 /* Block atomic egress */
@@ -966,26 +970,28 @@
 
 /* Downstream Port Containment */
 #define PCI_EXP_DPC_CAP			4	/* DPC Capability */
-#define PCI_EXP_DPC_IRQ			0x1f	/* DPC Interrupt Message Number */
-#define  PCI_EXP_DPC_CAP_RP_EXT		0x20	/* Root Port Extensions for DPC */
-#define  PCI_EXP_DPC_CAP_POISONED_TLP	0x40	/* Poisoned TLP Egress Blocking Supported */
-#define  PCI_EXP_DPC_CAP_SW_TRIGGER	0x80	/* Software Triggering Supported */
-#define  PCI_EXP_DPC_RP_PIO_LOG_SIZE	0xF00	/* RP PIO log size */
+#define PCI_EXP_DPC_IRQ			0x001F	/* Interrupt Message Number */
+#define  PCI_EXP_DPC_CAP_RP_EXT		0x0020	/* Root Port Extensions */
+#define  PCI_EXP_DPC_CAP_POISONED_TLP	0x0040	/* Poisoned TLP Egress Blocking Supported */
+#define  PCI_EXP_DPC_CAP_SW_TRIGGER	0x0080	/* Software Triggering Supported */
+#define  PCI_EXP_DPC_RP_PIO_LOG_SIZE	0x0F00	/* RP PIO Log Size */
 #define  PCI_EXP_DPC_CAP_DL_ACTIVE	0x1000	/* ERR_COR signal on DL_Active supported */
 
 #define PCI_EXP_DPC_CTL			6	/* DPC control */
-#define  PCI_EXP_DPC_CTL_EN_NONFATAL 	0x02	/* Enable trigger on ERR_NONFATAL message */
-#define  PCI_EXP_DPC_CTL_INT_EN 	0x08	/* DPC Interrupt Enable */
+#define  PCI_EXP_DPC_CTL_EN_NONFATAL 	0x0002	/* Enable trigger on ERR_NONFATAL message */
+#define  PCI_EXP_DPC_CTL_INT_EN 	0x0008	/* DPC Interrupt Enable */
 
 #define PCI_EXP_DPC_STATUS		8	/* DPC Status */
-#define  PCI_EXP_DPC_STATUS_TRIGGER	0x01	/* Trigger Status */
-#define  PCI_EXP_DPC_STATUS_INTERRUPT	0x08	/* Interrupt Status */
-#define  PCI_EXP_DPC_RP_BUSY		0x10	/* Root Port Busy */
+#define  PCI_EXP_DPC_STATUS_TRIGGER	    0x0001 /* Trigger Status */
+#define  PCI_EXP_DPC_STATUS_TRIGGER_RSN	    0x0006 /* Trigger Reason */
+#define  PCI_EXP_DPC_STATUS_INTERRUPT	    0x0008 /* Interrupt Status */
+#define  PCI_EXP_DPC_RP_BUSY		    0x0010 /* Root Port Busy */
+#define  PCI_EXP_DPC_STATUS_TRIGGER_RSN_EXT 0x0060 /* Trig Reason Extension */
 
 #define PCI_EXP_DPC_SOURCE_ID		10	/* DPC Source Identifier */
 
 #define PCI_EXP_DPC_RP_PIO_STATUS	 0x0C	/* RP PIO Status */
-#define PCI_EXP_DPC_RP_PIO_MASK		 0x10	/* RP PIO MASK */
+#define PCI_EXP_DPC_RP_PIO_MASK		 0x10	/* RP PIO Mask */
 #define PCI_EXP_DPC_RP_PIO_SEVERITY	 0x14	/* RP PIO Severity */
 #define PCI_EXP_DPC_RP_PIO_SYSERROR	 0x18	/* RP PIO SysError */
 #define PCI_EXP_DPC_RP_PIO_EXCEPTION	 0x1C	/* RP PIO Exception */
include/standard-headers/linux/virtio_net.h +13 -0
index 30ff24940d..e9f255ea3f 100644
@@ -57,6 +57,8 @@
 					 * Steering */
 #define VIRTIO_NET_F_CTRL_MAC_ADDR 23	/* Set MAC address */
 
+#define VIRTIO_NET_F_SPEED_DUPLEX 63	/* Device set linkspeed and duplex */
+
 #ifndef VIRTIO_NET_NO_LEGACY
 #define VIRTIO_NET_F_GSO	6	/* Host handles pkts w/ any GSO type */
 #endif /* VIRTIO_NET_NO_LEGACY */
@@ -76,6 +78,17 @@ struct virtio_net_config {
 	uint16_t max_virtqueue_pairs;
 	/* Default maximum transmit unit advice */
 	uint16_t mtu;
+	/*
+	 * speed, in units of 1Mb. All values 0 to INT_MAX are legal.
+	 * Any other value stands for unknown.
+	 */
+	uint32_t speed;
+	/*
+	 * 0x00 - half duplex
+	 * 0x01 - full duplex
+	 * Any other value stands for unknown.
+	 */
+	uint8_t duplex;
 } QEMU_PACKED;
 
 /*
linux-headers/asm-powerpc/kvm.h +2 -0
index 637b7263cb..833ed9a16a 100644
@@ -632,6 +632,8 @@ struct kvm_ppc_cpu_char {
 #define KVM_REG_PPC_TIDR	(KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbc)
 #define KVM_REG_PPC_PSSCR	(KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbd)
 
+#define KVM_REG_PPC_DEC_EXPIRY	(KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbe)
+
 /* Transactional Memory checkpointed state:
  * This is all GPRs, all VSX regs and a subset of SPRs
  */
linux-headers/asm-powerpc/unistd.h +3 -0
index 36abf58582..0c08edcfcd 100644
@@ -395,5 +395,8 @@
 #define __NR_pwritev2		381
 #define __NR_kexec_file_load	382
 #define __NR_statx		383
+#define __NR_pkey_alloc		384
+#define __NR_pkey_free		385
+#define __NR_pkey_mprotect	386
 
 #endif /* _ASM_POWERPC_UNISTD_H_ */
linux-headers/asm-s390/unistd.h +3 -398

408 lines not on this page · raw message

linux-headers/asm-s390/unistd_32.h new file +364 -0

364 lines not on this page · raw message

linux-headers/asm-s390/unistd_64.h new file +331 -0

331 lines not on this page · raw message

linux-headers/asm-x86/kvm_para.h +4 -0
index 4c300f6aaa..dc1ae0859e 100644
@@ -25,6 +25,7 @@
 #define KVM_FEATURE_STEAL_TIME		5
 #define KVM_FEATURE_PV_EOI		6
 #define KVM_FEATURE_PV_UNHALT		7
+#define KVM_FEATURE_PV_TLB_FLUSH	9
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
@@ -51,6 +52,9 @@ struct kvm_steal_time {
 	__u32 pad[11];
 };
 
+#define KVM_VCPU_PREEMPTED          (1 << 0)
+#define KVM_VCPU_FLUSH_TLB          (1 << 1)
+
 #define KVM_CLOCK_PAIRING_WALLCLOCK 0
 struct kvm_clock_pairing {
 	__s64 sec;
linux-headers/linux/kvm.h +90 -0

96 lines not on this page · raw message

linux-headers/linux/psci.h +3 -0
index ccd17731c6..3905492d18 100644
@@ -88,6 +88,9 @@
 		(((ver) & PSCI_VERSION_MAJOR_MASK) >> PSCI_VERSION_MAJOR_SHIFT)
 #define PSCI_VERSION_MINOR(ver)			\
 		((ver) & PSCI_VERSION_MINOR_MASK)
+#define PSCI_VERSION(maj, min)						\
+	((((maj) << PSCI_VERSION_MAJOR_SHIFT) & PSCI_VERSION_MAJOR_MASK) | \
+	 ((min) & PSCI_VERSION_MINOR_MASK))
 
 /* PSCI features decoding (>=1.0) */
 #define PSCI_1_0_FEATURES_CPU_SUSPEND_PF_SHIFT	1
linux-headers/linux/vfio.h +72 -0

84 lines not on this page · raw message

scripts/update-linux-headers.sh +3 -0
index 135a10d96a..cf387d5a5d 100755
@@ -54,6 +54,7 @@ cp_portable() {
         -e 's/__bitwise//' \
         -e 's/__attribute__((packed))/QEMU_PACKED/' \
         -e 's/__inline__/inline/' \
+        -e 's/__BITS_PER_LONG/HOST_LONG_BITS/' \
         -e '/sys\/ioctl.h/d' \
         -e 's/SW_MAX/SW_MAX_/' \
         "$f" > "$to/$header";
@@ -96,6 +97,8 @@ for arch in $ARCHLIST; do
     mkdir -p "$output/include/standard-headers/asm-$arch"
     if [ $arch = s390 ]; then
         cp_portable "$tmpdir/include/asm/virtio-ccw.h" "$output/include/standard-headers/asm-s390/"
+        cp "$tmpdir/include/asm/unistd_32.h" "$output/linux-headers/asm-s390/"
+        cp "$tmpdir/include/asm/unistd_64.h" "$output/linux-headers/asm-s390/"
     fi
     if [ $arch = arm ]; then
         cp "$tmpdir/include/asm/unistd-eabi.h" "$output/linux-headers/asm-arm/"
Signature · 1 line
2.9.3
#2 lore raw

PATCH v4 2/7 standard-headers: add drm/drm_fourcc.h

In reply to Gerd Hoffmann

So we can use the drm fourcc codes without a dependency on libdrm-devel.

---
 include/standard-headers/drm/drm_fourcc.h | 411 ++++++++++++++++++++++++++++++
 scripts/update-linux-headers.sh           |   4 +
 2 files changed, 415 insertions(+)
 create mode 100644 include/standard-headers/drm/drm_fourcc.h
include/standard-headers/drm/drm_fourcc.h new file +411 -0
new file mode 100644
index 0000000000..11912fde24
@@ -0,0 +1,411 @@
+/*
+ * Copyright 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef DRM_FOURCC_H
+#define DRM_FOURCC_H
+
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+#define fourcc_code(a, b, c, d) ((uint32_t)(a) | ((uint32_t)(b) << 8) | \
+				 ((uint32_t)(c) << 16) | ((uint32_t)(d) << 24))
+
+#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of little endian */
+
+/* color index */
+#define DRM_FORMAT_C8		fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
+
+/* 8 bpp Red */
+#define DRM_FORMAT_R8		fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+
+/* 16 bpp Red */
+#define DRM_FORMAT_R16		fourcc_code('R', '1', '6', ' ') /* [15:0] R little endian */
+
+/* 16 bpp RG */
+#define DRM_FORMAT_RG88		fourcc_code('R', 'G', '8', '8') /* [15:0] R:G 8:8 little endian */
+#define DRM_FORMAT_GR88		fourcc_code('G', 'R', '8', '8') /* [15:0] G:R 8:8 little endian */
+
+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616	fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 16:16 little endian */
+#define DRM_FORMAT_GR1616	fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 16:16 little endian */
+
+/* 8 bpp RGB */
+#define DRM_FORMAT_RGB332	fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 3:3:2 */
+#define DRM_FORMAT_BGR233	fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 2:3:3 */
+
+/* 16 bpp RGB */
+#define DRM_FORMAT_XRGB4444	fourcc_code('X', 'R', '1', '2') /* [15:0] x:R:G:B 4:4:4:4 little endian */
+#define DRM_FORMAT_XBGR4444	fourcc_code('X', 'B', '1', '2') /* [15:0] x:B:G:R 4:4:4:4 little endian */
+#define DRM_FORMAT_RGBX4444	fourcc_code('R', 'X', '1', '2') /* [15:0] R:G:B:x 4:4:4:4 little endian */
+#define DRM_FORMAT_BGRX4444	fourcc_code('B', 'X', '1', '2') /* [15:0] B:G:R:x 4:4:4:4 little endian */
+
+#define DRM_FORMAT_ARGB4444	fourcc_code('A', 'R', '1', '2') /* [15:0] A:R:G:B 4:4:4:4 little endian */
+#define DRM_FORMAT_ABGR4444	fourcc_code('A', 'B', '1', '2') /* [15:0] A:B:G:R 4:4:4:4 little endian */
+#define DRM_FORMAT_RGBA4444	fourcc_code('R', 'A', '1', '2') /* [15:0] R:G:B:A 4:4:4:4 little endian */
+#define DRM_FORMAT_BGRA4444	fourcc_code('B', 'A', '1', '2') /* [15:0] B:G:R:A 4:4:4:4 little endian */
+
+#define DRM_FORMAT_XRGB1555	fourcc_code('X', 'R', '1', '5') /* [15:0] x:R:G:B 1:5:5:5 little endian */
+#define DRM_FORMAT_XBGR1555	fourcc_code('X', 'B', '1', '5') /* [15:0] x:B:G:R 1:5:5:5 little endian */
+#define DRM_FORMAT_RGBX5551	fourcc_code('R', 'X', '1', '5') /* [15:0] R:G:B:x 5:5:5:1 little endian */
+#define DRM_FORMAT_BGRX5551	fourcc_code('B', 'X', '1', '5') /* [15:0] B:G:R:x 5:5:5:1 little endian */
+
+#define DRM_FORMAT_ARGB1555	fourcc_code('A', 'R', '1', '5') /* [15:0] A:R:G:B 1:5:5:5 little endian */
+#define DRM_FORMAT_ABGR1555	fourcc_code('A', 'B', '1', '5') /* [15:0] A:B:G:R 1:5:5:5 little endian */
+#define DRM_FORMAT_RGBA5551	fourcc_code('R', 'A', '1', '5') /* [15:0] R:G:B:A 5:5:5:1 little endian */
+#define DRM_FORMAT_BGRA5551	fourcc_code('B', 'A', '1', '5') /* [15:0] B:G:R:A 5:5:5:1 little endian */
+
+#define DRM_FORMAT_RGB565	fourcc_code('R', 'G', '1', '6') /* [15:0] R:G:B 5:6:5 little endian */
+#define DRM_FORMAT_BGR565	fourcc_code('B', 'G', '1', '6') /* [15:0] B:G:R 5:6:5 little endian */
+
+/* 24 bpp RGB */
+#define DRM_FORMAT_RGB888	fourcc_code('R', 'G', '2', '4') /* [23:0] R:G:B little endian */
+#define DRM_FORMAT_BGR888	fourcc_code('B', 'G', '2', '4') /* [23:0] B:G:R little endian */
+
+/* 32 bpp RGB */
+#define DRM_FORMAT_XRGB8888	fourcc_code('X', 'R', '2', '4') /* [31:0] x:R:G:B 8:8:8:8 little endian */
+#define DRM_FORMAT_XBGR8888	fourcc_code('X', 'B', '2', '4') /* [31:0] x:B:G:R 8:8:8:8 little endian */
+#define DRM_FORMAT_RGBX8888	fourcc_code('R', 'X', '2', '4') /* [31:0] R:G:B:x 8:8:8:8 little endian */
+#define DRM_FORMAT_BGRX8888	fourcc_code('B', 'X', '2', '4') /* [31:0] B:G:R:x 8:8:8:8 little endian */
+
+#define DRM_FORMAT_ARGB8888	fourcc_code('A', 'R', '2', '4') /* [31:0] A:R:G:B 8:8:8:8 little endian */
+#define DRM_FORMAT_ABGR8888	fourcc_code('A', 'B', '2', '4') /* [31:0] A:B:G:R 8:8:8:8 little endian */
+#define DRM_FORMAT_RGBA8888	fourcc_code('R', 'A', '2', '4') /* [31:0] R:G:B:A 8:8:8:8 little endian */
+#define DRM_FORMAT_BGRA8888	fourcc_code('B', 'A', '2', '4') /* [31:0] B:G:R:A 8:8:8:8 little endian */
+
+#define DRM_FORMAT_XRGB2101010	fourcc_code('X', 'R', '3', '0') /* [31:0] x:R:G:B 2:10:10:10 little endian */
+#define DRM_FORMAT_XBGR2101010	fourcc_code('X', 'B', '3', '0') /* [31:0] x:B:G:R 2:10:10:10 little endian */
+#define DRM_FORMAT_RGBX1010102	fourcc_code('R', 'X', '3', '0') /* [31:0] R:G:B:x 10:10:10:2 little endian */
+#define DRM_FORMAT_BGRX1010102	fourcc_code('B', 'X', '3', '0') /* [31:0] B:G:R:x 10:10:10:2 little endian */
+
+#define DRM_FORMAT_ARGB2101010	fourcc_code('A', 'R', '3', '0') /* [31:0] A:R:G:B 2:10:10:10 little endian */
+#define DRM_FORMAT_ABGR2101010	fourcc_code('A', 'B', '3', '0') /* [31:0] A:B:G:R 2:10:10:10 little endian */
+#define DRM_FORMAT_RGBA1010102	fourcc_code('R', 'A', '3', '0') /* [31:0] R:G:B:A 10:10:10:2 little endian */
+#define DRM_FORMAT_BGRA1010102	fourcc_code('B', 'A', '3', '0') /* [31:0] B:G:R:A 10:10:10:2 little endian */
+
+/* packed YCbCr */
+#define DRM_FORMAT_YUYV		fourcc_code('Y', 'U', 'Y', 'V') /* [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
+#define DRM_FORMAT_YVYU		fourcc_code('Y', 'V', 'Y', 'U') /* [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
+#define DRM_FORMAT_UYVY		fourcc_code('U', 'Y', 'V', 'Y') /* [31:0] Y1:Cr0:Y0:Cb0 8:8:8:8 little endian */
+#define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
+
+#define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+
+/*
+ * 2 plane RGB + A
+ * index 0 = RGB plane, same format as the corresponding non _A8 format has
+ * index 1 = A plane, [7:0] A
+ */
+#define DRM_FORMAT_XRGB8888_A8	fourcc_code('X', 'R', 'A', '8')
+#define DRM_FORMAT_XBGR8888_A8	fourcc_code('X', 'B', 'A', '8')
+#define DRM_FORMAT_RGBX8888_A8	fourcc_code('R', 'X', 'A', '8')
+#define DRM_FORMAT_BGRX8888_A8	fourcc_code('B', 'X', 'A', '8')
+#define DRM_FORMAT_RGB888_A8	fourcc_code('R', '8', 'A', '8')
+#define DRM_FORMAT_BGR888_A8	fourcc_code('B', '8', 'A', '8')
+#define DRM_FORMAT_RGB565_A8	fourcc_code('R', '5', 'A', '8')
+#define DRM_FORMAT_BGR565_A8	fourcc_code('B', '5', 'A', '8')
+
+/*
+ * 2 plane YCbCr
+ * index 0 = Y plane, [7:0] Y
+ * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
+ * or
+ * index 1 = Cb:Cr plane, [15:0] Cb:Cr little endian
+ */
+#define DRM_FORMAT_NV12		fourcc_code('N', 'V', '1', '2') /* 2x2 subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV21		fourcc_code('N', 'V', '2', '1') /* 2x2 subsampled Cb:Cr plane */
+#define DRM_FORMAT_NV16		fourcc_code('N', 'V', '1', '6') /* 2x1 subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
+#define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
+
+/*
+ * 3 plane YCbCr
+ * index 0: Y plane, [7:0] Y
+ * index 1: Cb plane, [7:0] Cb
+ * index 2: Cr plane, [7:0] Cr
+ * or
+ * index 1: Cr plane, [7:0] Cr
+ * index 2: Cb plane, [7:0] Cb
+ */
+#define DRM_FORMAT_YUV410	fourcc_code('Y', 'U', 'V', '9') /* 4x4 subsampled Cb (1) and Cr (2) planes */
+#define DRM_FORMAT_YVU410	fourcc_code('Y', 'V', 'U', '9') /* 4x4 subsampled Cr (1) and Cb (2) planes */
+#define DRM_FORMAT_YUV411	fourcc_code('Y', 'U', '1', '1') /* 4x1 subsampled Cb (1) and Cr (2) planes */
+#define DRM_FORMAT_YVU411	fourcc_code('Y', 'V', '1', '1') /* 4x1 subsampled Cr (1) and Cb (2) planes */
+#define DRM_FORMAT_YUV420	fourcc_code('Y', 'U', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes */
+#define DRM_FORMAT_YVU420	fourcc_code('Y', 'V', '1', '2') /* 2x2 subsampled Cr (1) and Cb (2) planes */
+#define DRM_FORMAT_YUV422	fourcc_code('Y', 'U', '1', '6') /* 2x1 subsampled Cb (1) and Cr (2) planes */
+#define DRM_FORMAT_YVU422	fourcc_code('Y', 'V', '1', '6') /* 2x1 subsampled Cr (1) and Cb (2) planes */
+#define DRM_FORMAT_YUV444	fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
+#define DRM_FORMAT_YVU444	fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
+
+
+/*
+ * Format Modifiers:
+ *
+ * Format modifiers describe, typically, a re-ordering or modification
+ * of the data in a plane of an FB.  This can be used to express tiled/
+ * swizzled formats, or compression, or a combination of the two.
+ *
+ * The upper 8 bits of the format modifier are a vendor-id as assigned
+ * below.  The lower 56 bits are assigned as vendor sees fit.
+ */
+
+/* Vendor Ids: */
+#define DRM_FORMAT_MOD_NONE           0
+#define DRM_FORMAT_MOD_VENDOR_NONE    0
+#define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
+#define DRM_FORMAT_MOD_VENDOR_AMD     0x02
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
+#define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
+#define DRM_FORMAT_MOD_VENDOR_QCOM    0x05
+#define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
+#define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
+/* add more to the end as needed */
+
+#define DRM_FORMAT_RESERVED	      ((1ULL << 56) - 1)
+
+#define fourcc_mod_code(vendor, val) \
+	((((uint64_t)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 0x00ffffffffffffffULL))
+
+/*
+ * Format Modifier tokens:
+ *
+ * When adding a new token please document the layout with a code comment,
+ * similar to the fourcc codes above. drm_fourcc.h is considered the
+ * authoritative source for all of these.
+ */
+
+/*
+ * Invalid Modifier
+ *
+ * This modifier can be used as a sentinel to terminate the format modifiers
+ * list, or to initialize a variable with an invalid modifier. It might also be
+ * used to report an error back to userspace for certain APIs.
+ */
+#define DRM_FORMAT_MOD_INVALID	fourcc_mod_code(NONE, DRM_FORMAT_RESERVED)
+
+/*
+ * Linear Layout
+ *
+ * Just plain linear layout. Note that this is different from no specifying any
+ * modifier (e.g. not setting DRM_MODE_FB_MODIFIERS in the DRM_ADDFB2 ioctl),
+ * which tells the driver to also take driver-internal information into account
+ * and so might actually result in a tiled framebuffer.
+ */
+#define DRM_FORMAT_MOD_LINEAR	fourcc_mod_code(NONE, 0)
+
+/* Intel framebuffer modifiers */
+
+/*
+ * Intel X-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
+ * in row-major layout. Within the tile bytes are laid out row-major, with
+ * a platform-dependent stride. On top of that the memory can apply
+ * platform-depending swizzling of some higher address bits into bit6.
+ *
+ * This format is highly platforms specific and not useful for cross-driver
+ * sharing. It exists since on a given platform it does uniquely identify the
+ * layout in a simple way for i915-specific userspace.
+ */
+#define I915_FORMAT_MOD_X_TILED	fourcc_mod_code(INTEL, 1)
+
+/*
+ * Intel Y-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
+ * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes)
+ * chunks column-major, with a platform-dependent height. On top of that the
+ * memory can apply platform-depending swizzling of some higher address bits
+ * into bit6.
+ *
+ * This format is highly platforms specific and not useful for cross-driver
+ * sharing. It exists since on a given platform it does uniquely identify the
+ * layout in a simple way for i915-specific userspace.
+ */
+#define I915_FORMAT_MOD_Y_TILED	fourcc_mod_code(INTEL, 2)
+
+/*
+ * Intel Yf-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles in row-major layout.
+ * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
+ * are arranged in four groups (two wide, two high) with column-major layout.
+ * Each group therefore consits out of four 256 byte units, which are also laid
+ * out as 2x2 column-major.
+ * 256 byte units are made out of four 64 byte blocks of pixels, producing
+ * either a square block or a 2:1 unit.
+ * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the width
+ * in pixel depends on the pixel depth.
+ */
+#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
+
+/*
+ * Intel color control surface (CCS) for render compression
+ *
+ * The framebuffer format must be one of the 8:8:8:8 RGB formats.
+ * The main surface will be plane index 0 and must be Y/Yf-tiled,
+ * the CCS will be plane index 1.
+ *
+ * Each CCS tile matches a 1024x512 pixel area of the main surface.
+ * To match certain aspects of the 3D hardware the CCS is
+ * considered to be made up of normal 128Bx32 Y tiles, Thus
+ * the CCS pitch must be specified in multiples of 128 bytes.
+ *
+ * In reality the CCS tile appears to be a 64Bx64 Y tile, composed
+ * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks.
+ * But that fact is not relevant unless the memory is accessed
+ * directly.
+ */
+#define I915_FORMAT_MOD_Y_TILED_CCS	fourcc_mod_code(INTEL, 4)
+#define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)
+
+/*
+ * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
+ *
+ * Macroblocks are laid in a Z-shape, and each pixel data is following the
+ * standard NV12 style.
+ * As for NV12, an image is the result of two frame buffers: one for Y,
+ * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer).
+ * Alignment requirements are (for each buffer):
+ * - multiple of 128 pixels for the width
+ * - multiple of  32 pixels for the height
+ *
+ * For more information: see https://linuxtv.org/downloads/v4l-dvb-apis/re32.html
+ */
+#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE	fourcc_mod_code(SAMSUNG, 1)
+
+/* Vivante framebuffer modifiers */
+
+/*
+ * Vivante 4x4 tiling layout
+ *
+ * This is a simple tiled layout using tiles of 4x4 pixels in a row-major
+ * layout.
+ */
+#define DRM_FORMAT_MOD_VIVANTE_TILED		fourcc_mod_code(VIVANTE, 1)
+
+/*
+ * Vivante 64x64 super-tiling layout
+ *
+ * This is a tiled layout using 64x64 pixel super-tiles, where each super-tile
+ * contains 8x4 groups of 2x4 tiles of 4x4 pixels (like above) each, all in row-
+ * major layout.
+ *
+ * For more information: see
+ * https://github.com/etnaviv/etna_viv/blob/master/doc/hardware.md#texture-tiling
+ */
+#define DRM_FORMAT_MOD_VIVANTE_SUPER_TILED	fourcc_mod_code(VIVANTE, 2)
+
+/*
+ * Vivante 4x4 tiling layout for dual-pipe
+ *
+ * Same as the 4x4 tiling layout, except every second 4x4 pixel tile starts at a
+ * different base address. Offsets from the base addresses are therefore halved
+ * compared to the non-split tiled layout.
+ */
+#define DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED	fourcc_mod_code(VIVANTE, 3)
+
+/*
+ * Vivante 64x64 super-tiling layout for dual-pipe
+ *
+ * Same as the 64x64 super-tiling layout, except every second 4x4 pixel tile
+ * starts at a different base address. Offsets from the base addresses are
+ * therefore halved compared to the non-split super-tiled layout.
+ */
+#define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
+
+/* NVIDIA frame buffer modifiers */
+
+/*
+ * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
+ *
+ * Pixels are arranged in simple tiles of 16 x 16 bytes.
+ */
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
+
+/*
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
+ *
+ * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
+ * vertically by a power of 2 (1 to 32 GOBs) to form a block.
+ *
+ * Within a GOB, data is ordered as 16B x 2 lines sectors laid in Z-shape.
+ *
+ * Parameter 'v' is the log2 encoding of the number of GOBs stacked vertically.
+ * Valid values are:
+ *
+ * 0 == ONE_GOB
+ * 1 == TWO_GOBS
+ * 2 == FOUR_GOBS
+ * 3 == EIGHT_GOBS
+ * 4 == SIXTEEN_GOBS
+ * 5 == THIRTYTWO_GOBS
+ *
+ * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
+ * in full detail.
+ */
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+	fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+	fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+	fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+	fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+	fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+	fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+	fourcc_mod_code(NVIDIA, 0x15)
+
+/*
+ * Broadcom VC4 "T" format
+ *
+ * This is the primary layout that the V3D GPU can texture from (it
+ * can't do linear).  The T format has:
+ *
+ * - 64b utiles of pixels in a raster-order grid according to cpp.  It's 4x4
+ *   pixels at 32 bit depth.
+ *
+ * - 1k subtiles made of a 4x4 raster-order grid of 64b utiles (so usually
+ *   16x16 pixels).
+ *
+ * - 4k tiles made of a 2x2 grid of 1k subtiles (so usually 32x32 pixels).  On
+ *   even 4k tile rows, they're arranged as (BL, TL, TR, BR), and on odd rows
+ *   they're (TR, BR, BL, TL), where bottom left is start of memory.
+ *
+ * - an image made of 4k tiles in rows either left-to-right (even rows of 4k
+ *   tiles) or right-to-left (odd rows of 4k tiles).
+ */
+#define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
+
+#if defined(__cplusplus)
+}
+#endif
+
+#endif /* DRM_FOURCC_H */
scripts/update-linux-headers.sh +4 -0
index cf387d5a5d..e6f1a06369 100755
@@ -38,6 +38,7 @@ cp_portable() {
                                      -e 'linux/if_ether' \
                                      -e 'input-event-codes' \
                                      -e 'sys/' \
+                                     -e 'drm.h' \
                                      > /dev/null
     then
         echo "Unexpected #include in input file $f".
@@ -55,6 +56,7 @@ cp_portable() {
         -e 's/__attribute__((packed))/QEMU_PACKED/' \
         -e 's/__inline__/inline/' \
         -e 's/__BITS_PER_LONG/HOST_LONG_BITS/' \
+        -e '/\"drm.h\"/d' \
         -e '/sys\/ioctl.h/d' \
         -e 's/SW_MAX/SW_MAX_/' \
         "$f" > "$to/$header";
@@ -149,6 +151,8 @@ for i in "$tmpdir"/include/linux/*virtio*.h "$tmpdir/include/linux/input.h" \
          "$tmpdir/include/linux/pci_regs.h"; do
     cp_portable "$i" "$output/include/standard-headers/linux"
 done
+mkdir -p "$output/include/standard-headers/drm"
+cp_portable "$tmpdir/include/drm/drm_fourcc.h" "$output/include/standard-headers/drm"
 
 cat <<EOF >$output/include/standard-headers/linux/types.h
 /* For QEMU all types are already defined via osdep.h, so this
Signature · 1 line
2.9.3
#3 lore raw

PATCH v4 3/7 ui/pixman: add qemu_drm_format_to_pixman()

In reply to Gerd Hoffmann

Map drm fourcc codes to pixman formats.

---
 include/ui/qemu-pixman.h |  5 +++++
 ui/qemu-pixman.c         | 22 ++++++++++++++++++++++
 2 files changed, 27 insertions(+)
include/ui/qemu-pixman.h +5 -0
index 4a67e01232..b7c82d17fc 100644
@@ -33,6 +33,8 @@
 # define PIXMAN_BE_r8g8b8a8   PIXMAN_r8g8b8a8
 # define PIXMAN_BE_x8b8g8r8   PIXMAN_x8b8g8r8
 # define PIXMAN_BE_a8b8g8r8   PIXMAN_a8b8g8r8
+# define PIXMAN_LE_r8g8b8     PIXMAN_b8g8r8
+# define PIXMAN_LE_a8r8g8b8   PIXMAN_b8g8r8a8
 # define PIXMAN_LE_x8r8g8b8   PIXMAN_b8g8r8x8
 #else
 # define PIXMAN_BE_r8g8b8     PIXMAN_b8g8r8
@@ -44,6 +46,8 @@
 # define PIXMAN_BE_r8g8b8a8   PIXMAN_a8b8g8r8
 # define PIXMAN_BE_x8b8g8r8   PIXMAN_r8g8b8x8
 # define PIXMAN_BE_a8b8g8r8   PIXMAN_r8g8b8a8
+# define PIXMAN_LE_r8g8b8     PIXMAN_r8g8b8
+# define PIXMAN_LE_a8r8g8b8   PIXMAN_a8r8g8b8
 # define PIXMAN_LE_x8r8g8b8   PIXMAN_x8r8g8b8
 #endif
 
@@ -51,6 +55,7 @@
 
 PixelFormat qemu_pixelformat_from_pixman(pixman_format_code_t format);
 pixman_format_code_t qemu_default_pixman_format(int bpp, bool native_endian);
+pixman_format_code_t qemu_drm_format_to_pixman(uint32_t drm_format);
 int qemu_pixman_get_type(int rshift, int gshift, int bshift);
 pixman_format_code_t qemu_pixman_get_format(PixelFormat *pf);
 bool qemu_pixman_check_format(DisplayChangeListener *dcl,
ui/qemu-pixman.c +22 -0
index 6e591ab821..3e52abd92d 100644
@@ -6,6 +6,7 @@
 #include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "ui/console.h"
+#include "standard-headers/drm/drm_fourcc.h"
 
 PixelFormat qemu_pixelformat_from_pixman(pixman_format_code_t format)
 {
@@ -88,6 +89,27 @@ pixman_format_code_t qemu_default_pixman_format(int bpp, bool native_endian)
     return 0;
 }
 
+/* Note: drm is little endian, pixman is native endian */
+pixman_format_code_t qemu_drm_format_to_pixman(uint32_t drm_format)
+{
+    static const struct {
+        uint32_t drm_format;
+        pixman_format_code_t pixman;
+    } map[] = {
+        { DRM_FORMAT_RGB888,   PIXMAN_LE_r8g8b8   },
+        { DRM_FORMAT_ARGB8888, PIXMAN_LE_a8r8g8b8 },
+        { DRM_FORMAT_XRGB8888, PIXMAN_LE_x8r8g8b8 }
+    };
+    int i;
+
+    for (i = 0; i < ARRAY_SIZE(map); i++) {
+        if (drm_format == map[i].drm_format) {
+            return map[i].pixman;
+        }
+    }
+    return 0;
+}
+
 int qemu_pixman_get_type(int rshift, int gshift, int bshift)
 {
     int type = PIXMAN_TYPE_OTHER;
Signature · 1 line
2.9.3
#4 lore raw

PATCH v4 4/7 qdev: add hotpluggable to DeviceState

In reply to Gerd Hoffmann

vfio display support wants disable hotplug for certain devices, because qemu doesn't support hotplugging display devices and qemu consoles.

Add a hotpluggable bool to DeviceState, initialize it from DeviceClass->hotpluggable, update device_get_hotpluggable accordingly.

Devices can flip the new variable from true to false if needed.

---
 include/hw/qdev-core.h | 1 +
 hw/core/qdev.c         | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)
include/hw/qdev-core.h +1 -0
index fc9d617a76..37d86f26e5 100644
@@ -154,6 +154,7 @@ struct DeviceState {
     const char *id;
     char *canonical_path;
     bool realized;
+    bool hotpluggable;
     bool pending_deleted_event;
     QemuOpts *opts;
     int hotplugged;
hw/core/qdev.c +3 -2
index 7ed1f431f0..89e03c7b47 100644
@@ -946,8 +946,8 @@ static bool device_get_hotpluggable(Object *obj, Error **errp)
     DeviceClass *dc = DEVICE_GET_CLASS(obj);
     DeviceState *dev = DEVICE(obj);
 
-    return dc->hotpluggable && (dev->parent_bus == NULL ||
-                                qbus_is_hotpluggable(dev->parent_bus));
+    return dc->hotpluggable && dev->hotpluggable &&
+        (dev->parent_bus == NULL || qbus_is_hotpluggable(dev->parent_bus));
 }
 
 static bool device_get_hotplugged(Object *obj, Error **err)
@@ -988,6 +988,7 @@ static void device_initfn(Object *obj)
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
 
+    dev->hotpluggable = DEVICE_CLASS(class)->hotpluggable;
     object_property_add_link(OBJECT(dev), "parent_bus", TYPE_BUS,
                              (Object **)&dev->parent_bus, NULL, 0,
                              &error_abort);
Signature · 1 line
2.9.3
#5 lore raw

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState

Quoted 7 lines · Gerd Hoffmann

vfio display support wants disable hotplug for certain devices, because qemu doesn't support hotplugging display devices and qemu consoles.

Add a hotpluggable bool to DeviceState, initialize it from DeviceClass->hotpluggable, update device_get_hotpluggable accordingly.

Devices can flip the new variable from true to false if needed.

Alex wants an ack for this one. Who maintains it these days?

MAINTAINERS doesn't list qdev. For QOM which is closest probably Andreas Färber is listed. Havn't seen him on the list for a while though.

Ok, lets try some usual suspects...
Markus? Eric? Paolo? Peter? Any comments on this one?

thanks,
Gerd

Quoted 44 lines
---
 include/hw/qdev-core.h | 1 +
 hw/core/qdev.c         | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)
include/hw/qdev-core.h +1 -0
index fc9d617a76..37d86f26e5 100644
@@ -154,6 +154,7 @@ struct DeviceState {
     const char *id;
     char *canonical_path;
     bool realized;
+    bool hotpluggable;
     bool pending_deleted_event;
     QemuOpts *opts;
     int hotplugged;
hw/core/qdev.c +3 -2
index 7ed1f431f0..89e03c7b47 100644
@@ -946,8 +946,8 @@ static bool device_get_hotpluggable(Object *obj, Error **errp)
     DeviceClass *dc = DEVICE_GET_CLASS(obj);
     DeviceState *dev = DEVICE(obj);
 
-    return dc->hotpluggable && (dev->parent_bus == NULL ||
-                                qbus_is_hotpluggable(dev->parent_bus));
+    return dc->hotpluggable && dev->hotpluggable &&
+        (dev->parent_bus == NULL || qbus_is_hotpluggable(dev->parent_bus));
 }
 
 static bool device_get_hotplugged(Object *obj, Error **err)
@@ -988,6 +988,7 @@ static void device_initfn(Object *obj)
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
 
+    dev->hotpluggable = DEVICE_CLASS(class)->hotpluggable;
     object_property_add_link(OBJECT(dev), "parent_bus", TYPE_BUS,
                              (Object **)&dev->parent_bus, NULL, 0,
                              &error_abort);
Signature · 1 line
2.9.3
#6 lore raw

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState

Quoted 9 lines · Gerd Hoffmann
Quoted 7 lines · Gerd Hoffmann

vfio display support wants disable hotplug for certain devices, because qemu doesn't support hotplugging display devices and qemu consoles.

Add a hotpluggable bool to DeviceState, initialize it from DeviceClass->hotpluggable, update device_get_hotpluggable accordingly.

Devices can flip the new variable from true to false if needed.

Quoted 8 lines

Alex wants an ack for this one. Who maintains it these days?

MAINTAINERS doesn't list qdev. For QOM which is closest probably Andreas Färber is listed. Havn't seen him on the list for a while though.

Ok, lets try some usual suspects...
Markus? Eric? Paolo? Peter? Any comments on this one?

What type of device is only sometimes hotpluggable ? The commit message says "display devices" and "consoles", but I would expect those to both be types of device which have a class which is never hotpluggable, so you can mark them non-hotpluggable with the existing class flag rather than needing a per-instance flag.

thanks
-- PMM

#7 lore raw

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState

Quoted 19 lines · On Thu, 22 Feb 2018 15:46:17 +0000 Peter Maydell <[email protected]>…
Quoted 9 lines · Gerd Hoffmann
Quoted 7 lines · Gerd Hoffmann

vfio display support wants disable hotplug for certain devices, because qemu doesn't support hotplugging display devices and qemu consoles.

Add a hotpluggable bool to DeviceState, initialize it from DeviceClass->hotpluggable, update device_get_hotpluggable accordingly.

Devices can flip the new variable from true to false if needed.

Quoted 8 lines

Alex wants an ack for this one. Who maintains it these days?

MAINTAINERS doesn't list qdev. For QOM which is closest probably Andreas Färber is listed. Havn't seen him on the list for a while though.

Ok, lets try some usual suspects...
Markus? Eric? Paolo? Peter? Any comments on this one?

Quoted 6 lines

What type of device is only sometimes hotpluggable ? The commit message says "display devices" and "consoles", but I would expect those to both be types of device which have a class which is never hotpluggable, so you can mark them non-hotpluggable with the existing class flag rather than needing a per-instance flag.

With this series, a vfio-pci device optionally supports a display. The vfio-pci device is hotpluggable, but QEMU display support is not. So the solution here is to make the vfio-pci device non-hotpluggable only when it supports and enables a display.

Gerd, is there another solution that the display object is instantiated separately from the vfio-pci object and the display support in the vfio-pci device references the display object via an id. Possibly vfio-pci could remain hotpluggable while the display class device is not. Potentially one display could be switched between multiple display capable devices, like an input control button on a monitor, losing signal if none are connected. Possible? Clearly I have no idea how display objects actually work in QEMU. Thanks,

Alex

#8 lore raw

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState

Quoted 9 lines · Alex Williamson
Quoted 6 lines · On Thu, 22 Feb 2018 15:46:17 +0000 Peter Maydell <[email protected]>…

What type of device is only sometimes hotpluggable ? The commit message says "display devices" and "consoles", but I would expect those to both be types of device which have a class which is never hotpluggable, so you can mark them non-hotpluggable with the existing class flag rather than needing a per-instance flag.

Quoted 4 lines

With this series, a vfio-pci device optionally supports a display. The vfio-pci device is hotpluggable, but QEMU display support is not. So the solution here is to make the vfio-pci device non-hotpluggable only when it supports and enables a display.

Ah, I see. I don't have a good suggestion offhand, but I suspect the patch as it stands is insufficient if we want to take the approach it uses. For instance qdev_unplug() in qdev-monitor.c looks directly at dc->hotpluggable to decide whether it should refuse a user request to hot-unplug a device.

thanks
-- PMM

#9 lore raw

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState

In reply to Alex Williamson
Quoted 29 lines · Alex Williamson
Quoted 19 lines · On Thu, 22 Feb 2018 15:46:17 +0000 Peter Maydell <[email protected]>…
Quoted 9 lines · Gerd Hoffmann
Quoted 7 lines · Gerd Hoffmann

vfio display support wants disable hotplug for certain devices, because qemu doesn't support hotplugging display devices and qemu consoles.

Add a hotpluggable bool to DeviceState, initialize it from DeviceClass->hotpluggable, update device_get_hotpluggable accordingly.

Devices can flip the new variable from true to false if needed.

Quoted 8 lines

Alex wants an ack for this one. Who maintains it these days?

MAINTAINERS doesn't list qdev. For QOM which is closest probably Andreas Färber is listed. Havn't seen him on the list for a while though.

Ok, lets try some usual suspects...
Markus? Eric? Paolo? Peter? Any comments on this one?

Quoted 6 lines

What type of device is only sometimes hotpluggable ? The commit message says "display devices" and "consoles", but I would expect those to both be types of device which have a class which is never hotpluggable, so you can mark them non-hotpluggable with the existing class flag rather than needing a per-instance flag.

Quoted 5 lines

With this series, a vfio-pci device optionally supports a display. The vfio-pci device is hotpluggable, but QEMU display support is not. So the solution here is to make the vfio-pci device non-hotpluggable only when it supports and enables a display.

I'm not sure, how this is supposed to work?

And there's also case that vgpu's display is not required but still need device hotplug feature e.g to use render/media acceleration, as supported by current vfio mdev device on gvt-g.

Quoted 14 lines

Gerd, is there another solution that the display object is instantiated separately from the vfio-pci object and the display support in the vfio-pci device references the display object via an id. Possibly vfio-pci could remain hotpluggable while the display class device is not. Potentially one display could be switched between multiple display capable devices, like an input control button on a monitor, losing signal if none are connected. Possible? Clearly I have no idea how display objects actually work in QEMU. Thanks,

Alex
_______________________________________________
intel-gvt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

Signature · 3 lines
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
#10 lore raw

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState

In reply to Alex Williamson

Hi,

Quoted 7 lines
Quoted 6 lines

What type of device is only sometimes hotpluggable ? The commit message says "display devices" and "consoles", but I would expect those to both be types of device which have a class which is never hotpluggable, so you can mark them non-hotpluggable with the existing class flag rather than needing a per-instance flag.

Quoted 8 lines

With this series, a vfio-pci device optionally supports a display. The vfio-pci device is hotpluggable, but QEMU display support is not. So the solution here is to make the vfio-pci device non-hotpluggable only when it supports and enables a display.

Gerd, is there another solution that the display object is instantiated separately from the vfio-pci object and the display support in the vfio-pci device references the display object via an id.

Well, not really. At least not without putting much of qemu display support upside down. The qemu display (aka QemuConsole) is created and managed by the display devices, they can't be created independant from a device ...

The connection between QemuConsole and User Interface (i.e. gtk, spice, ...) is a bit more flexible. But also not really designed for hotplug as QemuConsole is not hotpluggable in the first place ...

We could drop the display property and use two devices instead.

new vfio-pci would behave like display=off with this series. added vfio-pci-display has display=on behavior. display=auto is not possible.

cheers,
Gerd

#11 lore raw

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState

Quoted 27 lines · On Fri, 23 Feb 2018 09:53:22 +0100 Gerd Hoffmann <[email protected]> wrote:

Hi,

Quoted 7 lines
Quoted 6 lines

What type of device is only sometimes hotpluggable ? The commit message says "display devices" and "consoles", but I would expect those to both be types of device which have a class which is never hotpluggable, so you can mark them non-hotpluggable with the existing class flag rather than needing a per-instance flag.

Quoted 8 lines

With this series, a vfio-pci device optionally supports a display. The vfio-pci device is hotpluggable, but QEMU display support is not. So the solution here is to make the vfio-pci device non-hotpluggable only when it supports and enables a display.

Gerd, is there another solution that the display object is instantiated separately from the vfio-pci object and the display support in the vfio-pci device references the display object via an id.

Well, not really. At least not without putting much of qemu display support upside down. The qemu display (aka QemuConsole) is created and managed by the display devices, they can't be created independant from a device ...

The connection between QemuConsole and User Interface (i.e. gtk, spice, ...) is a bit more flexible. But also not really designed for hotplug as QemuConsole is not hotpluggable in the first place ...

Quoted 5 lines

We could drop the display property and use two devices instead.

new vfio-pci would behave like display=off with this series. added vfio-pci-display has display=on behavior. display=auto is not possible.

I expect libvirt and above would balk at creating a separate QEMU device for this purpose, easy for QEMU, hard for anything that manages QEMU. Thanks,

Alex

#12 lore raw

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState

Hi,

Quoted 6 lines
Quoted 6 lines

The connection between QemuConsole and User Interface (i.e. gtk, spice, ...) is a bit more flexible. But also not really designed for hotplug as QemuConsole is not hotpluggable in the first place ...

We could drop the display property and use two devices instead.

Quoted 7 lines
Quoted 3 lines

new vfio-pci would behave like display=off with this series. added vfio-pci-display has display=on behavior. display=auto is not possible.

I expect libvirt and above would balk at creating a separate QEMU device for this purpose, easy for QEMU, hard for anything that manages QEMU.

Now as you've mentioned libvirt I remember we had the same discussion before, with usb host adapters. The uhci and ehci controllers have a simliar issue: If they are configured as companion setup (ehci for usb2 and uhci for usb1) they can't be hotplugged, as standalone controller hotplugging works fine.

We ended up with splitting the controllers into two groups: The ones which can be used in a companion setup (basically all ich9-* devices)
which are not hotpluggable. And the other ones which don't support
companion setups but can be hotplugged. Commits:

ec56214f6f usb: tag standalone ehci as hotpluggable 638ca939d8 usb: tag standalone uhci as hotpluggable

The argument from the libvirt side was that it is actually easier for them to handle if hotplugging is a fixed property of a device and doesn't change magically depending on device configuration. First because they can query qemu then whenever a given device can be hotplugged or not, and second because it'll work for both plug-in and plug-out.

So this patch isn't going to fly, and unless someone can come up with a better idea I'll go use the two-devices approach.

cheers,
Gerd

#13 lore raw

PATCH v4 5/7 vfio/common: cleanup in vfio_region_finalize

In reply to Gerd Hoffmann
---
 hw/vfio/common.c | 7 +++++++
 1 file changed, 7 insertions(+)
hw/vfio/common.c +7 -0
index f895e3c335..6a8203a532 100644
@@ -858,6 +858,13 @@ void vfio_region_finalize(VFIORegion *region)
     g_free(region->mmaps);
 
     trace_vfio_region_finalize(region->vbasedev->name, region->nr);
+
+    region->mem = NULL;
+    region->mmaps = NULL;
+    region->nr_mmaps = 0;
+    region->size = 0;
+    region->flags = 0;
+    region->nr = 0;
 }
 
 void vfio_region_mmaps_set_enabled(VFIORegion *region, bool enabled)
Signature · 1 line
2.9.3
#14 lore raw

PATCH v4 6/7 vfio/display: core & wireup

In reply to Gerd Hoffmann

Infrastructure for display support. Must be enabled using 'display' property.

---
 hw/vfio/pci.h         |  3 +++
 hw/vfio/display.c     | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/vfio/pci.c         |  9 +++++++++
 hw/vfio/Makefile.objs |  2 +-
 4 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 hw/vfio/display.c
hw/vfio/pci.h +3 -0
index f4aa13e021..1d005d922d 100644
@@ -133,6 +133,7 @@ typedef struct VFIOPCIDevice {
 #define VFIO_FEATURE_ENABLE_IGD_OPREGION_BIT 2
 #define VFIO_FEATURE_ENABLE_IGD_OPREGION \
                                 (1 << VFIO_FEATURE_ENABLE_IGD_OPREGION_BIT)
+    OnOffAuto display;
     int32_t bootindex;
     uint32_t igd_gms;
     OffAutoPCIBAR msix_relo;
@@ -174,4 +175,6 @@ int vfio_pci_igd_opregion_init(VFIOPCIDevice *vdev,
                                struct vfio_region_info *info,
                                Error **errp);
 
+int vfio_display_probe(VFIOPCIDevice *vdev, Error **errp);
+
 #endif /* HW_VFIO_VFIO_PCI_H */
hw/vfio/display.c new file +52 -0

52 lines not on this page · raw message

hw/vfio/pci.c +9 -0
index 033cc8dea1..8e6722791c 100644
@@ -3015,6 +3015,13 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
         }
     }
 
+    if (vdev->display != ON_OFF_AUTO_OFF) {
+        ret = vfio_display_probe(vdev, errp);
+        if (ret) {
+            goto out_teardown;
+        }
+    }
+
     vfio_register_err_notifier(vdev);
     vfio_register_req_notifier(vdev);
     vfio_setup_resetfn_quirk(vdev);
@@ -3123,6 +3130,8 @@ static void vfio_instance_init(Object *obj)
 static Property vfio_pci_dev_properties[] = {
     DEFINE_PROP_PCI_HOST_DEVADDR("host", VFIOPCIDevice, host),
     DEFINE_PROP_STRING("sysfsdev", VFIOPCIDevice, vbasedev.sysfsdev),
+    DEFINE_PROP_ON_OFF_AUTO("display", VFIOPCIDevice,
+                            display, ON_OFF_AUTO_AUTO),
     DEFINE_PROP_UINT32("x-intx-mmap-timeout-ms", VFIOPCIDevice,
                        intx.mmap_timeout, 1100),
     DEFINE_PROP_BIT("x-vga", VFIOPCIDevice, features,
hw/vfio/Makefile.objs +1 -1
index c3ab9097f1..a2e7a0a7cf 100644
@@ -1,6 +1,6 @@
 ifeq ($(CONFIG_LINUX), y)
 obj-$(CONFIG_SOFTMMU) += common.o
-obj-$(CONFIG_PCI) += pci.o pci-quirks.o
+obj-$(CONFIG_PCI) += pci.o pci-quirks.o display.o
 obj-$(CONFIG_VFIO_CCW) += ccw.o
 obj-$(CONFIG_SOFTMMU) += platform.o
 obj-$(CONFIG_VFIO_XGMAC) += calxeda-xgmac.o
Signature · 1 line
2.9.3
#15 lore raw

PATCH v4 7/7 vfio/display: adding region support

In reply to Gerd Hoffmann

Wire up region-based display.

---
 hw/vfio/pci.h                 |   1 +
 include/hw/vfio/vfio-common.h |   8 ++++
 hw/vfio/display.c             | 104 +++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 111 insertions(+), 2 deletions(-)
hw/vfio/pci.h +1 -0
index 1d005d922d..9fe0f3f198 100644
@@ -148,6 +148,7 @@ typedef struct VFIOPCIDevice {
     bool no_kvm_msi;
     bool no_kvm_msix;
     bool no_geforce_quirks;
+    VFIODisplay *dpy;
 } VFIOPCIDevice;
 
 uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);
include/hw/vfio/vfio-common.h +8 -0
index f3a2ac9fee..fc8ae14fb7 100644
@@ -142,6 +142,14 @@ typedef struct VFIOGroup {
     QLIST_ENTRY(VFIOGroup) container_next;
 } VFIOGroup;
 
+typedef struct VFIODisplay {
+    QemuConsole *con;
+    struct {
+        VFIORegion buffer;
+        DisplaySurface *surface;
+    } region;
+} VFIODisplay;
+
 void vfio_put_base_device(VFIODevice *vbasedev);
 void vfio_disable_irqindex(VFIODevice *vbasedev, int index);
 void vfio_unmask_single_irqindex(VFIODevice *vbasedev, int index);
hw/vfio/display.c +102 -2

116 lines not on this page · raw message

Signature · 1 line
2.9.3
Acked-by on the v4 series
#16 lore raw
In reply to Gerd Hoffmann
Quoted 6 lines · On Mon, 19 Feb 2018 12:14:51 +0100 Gerd Hoffmann <[email protected]> wrote:

This series adds support for a vgpu display to the qemu vfio code. For now only regions are supported, dmabufs will follow later.

This version adds a patch to allow devices disable hotplugging, which will be used by vfio display support. Also fixed issues Alex found in review.

Looks ok to me, if this is to go through my tree I'll need a qdev ack for 4/7. If you want to go a different route, for 5-7:

I'm still a bit confused though, what's preventing us from adding dmabuf support now? It's strange to provide the implementation for the proprietary, unavailable vendor driver implementation first. Is GVT-g broken, lagging? Thanks,

Alex

Quoted 40 lines

Gerd Hoffmann (7):
linux-headers: update to 4.16-rc1
standard-headers: add drm/drm_fourcc.h
ui/pixman: add qemu_drm_format_to_pixman()
qdev: add hotpluggable to DeviceState
vfio/common: cleanup in vfio_region_finalize
vfio/display: core & wireup
vfio/display: adding region support

 hw/vfio/pci.h                                      |   4 +
 include/hw/qdev-core.h                             |   1 +
 include/hw/vfio/vfio-common.h                      |   8 +
 include/standard-headers/drm/drm_fourcc.h          | 411 +++++++++++++++++++++
 include/standard-headers/linux/input-event-codes.h |   1 +
 include/standard-headers/linux/input.h             |  11 +
 include/standard-headers/linux/pci_regs.h          |  30 +-
 include/standard-headers/linux/virtio_net.h        |  13 +
 include/ui/qemu-pixman.h                           |   5 +
 linux-headers/asm-powerpc/kvm.h                    |   2 +
 linux-headers/asm-powerpc/unistd.h                 |   3 +
 linux-headers/asm-s390/unistd.h                    | 401 +-------------------
 linux-headers/asm-s390/unistd_32.h                 | 364 ++++++++++++++++++
 linux-headers/asm-s390/unistd_64.h                 | 331 +++++++++++++++++
 linux-headers/asm-x86/kvm_para.h                   |   4 +
 linux-headers/linux/kvm.h                          |  90 +++++
 linux-headers/linux/psci.h                         |   3 +
 linux-headers/linux/vfio.h                         |  72 ++++
 hw/core/qdev.c                                     |   5 +-
 hw/vfio/common.c                                   |   7 +
 hw/vfio/display.c                                  | 152 ++++++++
 hw/vfio/pci.c                                      |   9 +
 ui/qemu-pixman.c                                   |  22 ++
 hw/vfio/Makefile.objs                              |   2 +-
 scripts/update-linux-headers.sh                    |   7 +
 25 files changed, 1545 insertions(+), 413 deletions(-)
 create mode 100644 include/standard-headers/drm/drm_fourcc.h
 create mode 100644 linux-headers/asm-s390/unistd_32.h
 create mode 100644 linux-headers/asm-s390/unistd_64.h
 create mode 100644 hw/vfio/display.c
#17 lore raw
Quoted 13 lines · Alex Williamson
Quoted 6 lines · On Mon, 19 Feb 2018 12:14:51 +0100 Gerd Hoffmann <[email protected]> wrote:

This series adds support for a vgpu display to the qemu vfio code. For now only regions are supported, dmabufs will follow later.

This version adds a patch to allow devices disable hotplugging, which will be used by vfio display support. Also fixed issues Alex found in review.

Looks ok to me, if this is to go through my tree I'll need a qdev ack for 4/7. If you want to go a different route, for 5-7:

Quoted 6 lines

I'm still a bit confused though, what's preventing us from adding dmabuf support now? It's strange to provide the implementation for the proprietary, unavailable vendor driver implementation first. Is GVT-g broken, lagging? Thanks,

A bit more complicated because it depends on user interface changes ...

Sneak preview at https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu
Note: branch is a moving target ;)

State:
vfio: Working, needs some cleanups though (drop debug logging, ...).
gtk: Working, needs some minor cleanups too.
spice: Partly working (no mouse ptr yet).
sdl: Not working. Need to figure how I get a egl context (instead
of glx). Possibly requires SDL 2.2. Tina looked at this a while back, need to look at some old mails ...

Current plan:
(1) fix/complete spice support.
(2) cleanup patches, send them out.
(3) look at the SDL issues.

#18 lore raw

Hi,

Quoted 5 lines

Sneak preview at https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu
Note: branch is a moving target ;)

State:
spice: Partly working (no mouse ptr yet).

Working now, in case anyone wants play.

Must turn on opengl and use a unix socket, i.e. this:

qemu -spice disable-ticketing,gl=on,unix,addr=/tmp/spice-vgpu

and this:

remote-viewer spice+unix:////tmp/spice-vgpu

Host needs a 4.16-rc kernel.

Guest can be older, most of the time I'm testing with the Fedora 27 live iso (4.13) which works ok.

cheers,
Gerd

#19 lore raw
Quoted 14 lines · Gerd Hoffmann

Hi,

Quoted 5 lines

Sneak preview at https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu
Note: branch is a moving target ;)

State:
spice: Partly working (no mouse ptr yet).

Working now, in case anyone wants play.

Must turn on opengl and use a unix socket, i.e. this:

qemu -spice disable-ticketing,gl=on,unix,addr=/tmp/spice-vgpu

Quoted 9 lines

and this:

remote-viewer spice+unix:////tmp/spice-vgpu

Host needs a 4.16-rc kernel.

Guest can be older, most of the time I'm testing with the Fedora 27 live iso (4.13) which works ok.

Nice! Seems to be the last missing gap for local spice with cursor dmabuf support, we'll do more testing on that for sure. Btw, another method might be to add direct cursor dmabuf passing for spice as gl output, is that correct way?

And really like to see dmabuf support could be in upstream soon. Do you have any predict for which qemu version?

Thanks!

Signature · 3 lines
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
#20 lore raw

Hi,

Quoted 4 lines

Nice! Seems to be the last missing gap for local spice with cursor dmabuf support, we'll do more testing on that for sure. Btw, another method might be to add direct cursor dmabuf passing for spice as gl output, is that correct way?

Passing on the cursor sprite needs the hotspot information, so spice client can position the cursor correctly. I didn't got hotspot information in my testing yet, but maybe the guest kernel was too old. Is that supported meanwhile? If so, which kernel version is needed?

Spice already has support for setting pointers, we can simply use that, at least initially. Doesn't use dma-bufs. If it turns out to be a performance issue we can add support for using dma-bufs instead, but that needs spice server changes.

Quoted 2 lines

And really like to see dmabuf support could be in upstream soon. Do you have any predict for which qemu version?

I want have this in 2.12, at least the current, initial version. Improved cursor support might take a little longer.

cheers,
Gerd

#21 lore raw
Quoted 7 lines · Gerd Hoffmann

Hi,

Quoted 4 lines

Nice! Seems to be the last missing gap for local spice with cursor dmabuf support, we'll do more testing on that for sure. Btw, another method might be to add direct cursor dmabuf passing for spice as gl output, is that correct way?

Quoted 5 lines

Passing on the cursor sprite needs the hotspot information, so spice client can position the cursor correctly. I didn't got hotspot information in my testing yet, but maybe the guest kernel was too old. Is that supported meanwhile? If so, which kernel version is needed?

Current gvt dmabuf doesn't support true hotspot info yet which requires some pv info update as we can't get it from hw state. Tina is pursuing that.

Quoted 11 lines

Spice already has support for setting pointers, we can simply use that, at least initially. Doesn't use dma-bufs. If it turns out to be a performance issue we can add support for using dma-bufs instead, but that needs spice server changes.

Quoted 2 lines

And really like to see dmabuf support could be in upstream soon. Do you have any predict for which qemu version?

I want have this in 2.12, at least the current, initial version. Improved cursor support might take a little longer.

Good to know. Thanks!

Signature · 3 lines
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
#22 lore raw
Quoted 19 lines

-----Original Message-----
From: Zhenyu Wang [mailto:[email protected]]
Sent: Friday, February 23, 2018 10:43 AM
To: Gerd Hoffmann <[email protected]>
Cc: Alex Williamson <[email protected]>; Kirti Wankhede <[email protected]>; [email protected]; qemu- [email protected]; Zhang, Tina <[email protected]>
Subject: Re: [Qemu-devel] [PATCH v4 0/7] vfio: add display support

Quoted 7 lines · Gerd Hoffmann

Hi,

Quoted 4 lines

Nice! Seems to be the last missing gap for local spice with cursor dmabuf support, we'll do more testing on that for sure. Btw, another method might be to add direct cursor dmabuf passing for spice as gl output, is that correct way?

Quoted 8 lines
Quoted 5 lines

Passing on the cursor sprite needs the hotspot information, so spice client can position the cursor correctly. I didn't got hotspot information in my testing yet, but maybe the guest kernel was too old. Is that supported meanwhile? If so, which kernel version is needed?

Current gvt dmabuf doesn't support true hotspot info yet which requires some pv info update as we can't get it from hw state. Tina is pursuing that.

Indeed. Guest OS needs to use pv info to deliver the hotspot info to host. And so far, only Windows igfx driver can support it.
With the following patch, host userspace can get the valid hotspot info if it is supported by guest driver (e.g. Windows), or invalid hotspot info when unsupported.
https://lists.freedesktop.org/archives/intel-gvt-dev/2018-February/003169.html

BR,
Tina

Quoted 19 lines
Quoted 6 lines

Spice already has support for setting pointers, we can simply use that, at least initially. Doesn't use dma-bufs. If it turns out to be a performance issue we can add support for using dma-bufs instead, but that needs spice server changes.

Quoted 6 lines
Quoted 2 lines

And really like to see dmabuf support could be in upstream soon. Do you have any predict for which qemu version?

I want have this in 2.12, at least the current, initial version. Improved cursor support might take a little longer.

Good to know. Thanks!

--
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

#23 lore raw
In reply to Gerd Hoffmann
Quoted 34 lines · On Tue, 20 Feb 2018 11:28:14 +0100 Gerd Hoffmann <[email protected]> wrote:
Quoted 13 lines · Alex Williamson
Quoted 6 lines · On Mon, 19 Feb 2018 12:14:51 +0100 Gerd Hoffmann <[email protected]> wrote:

This series adds support for a vgpu display to the qemu vfio code. For now only regions are supported, dmabufs will follow later.

This version adds a patch to allow devices disable hotplugging, which will be used by vfio display support. Also fixed issues Alex found in review.

Looks ok to me, if this is to go through my tree I'll need a qdev ack for 4/7. If you want to go a different route, for 5-7:

Quoted 6 lines

I'm still a bit confused though, what's preventing us from adding dmabuf support now? It's strange to provide the implementation for the proprietary, unavailable vendor driver implementation first. Is GVT-g broken, lagging? Thanks,

A bit more complicated because it depends on user interface changes ...

Sneak preview at https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu
Note: branch is a moving target ;)

State:
vfio: Working, needs some cleanups though (drop debug logging, ...).
gtk: Working, needs some minor cleanups too.
spice: Partly working (no mouse ptr yet).
sdl: Not working. Need to figure how I get a egl context (instead
of glx). Possibly requires SDL 2.2. Tina looked at this a while back, need to look at some old mails ...

Quoted 4 lines

Current plan:
(1) fix/complete spice support.
(2) cleanup patches, send them out.
(3) look at the SDL issues.

Hi Gerd,

It's a little bit concerning that the only way we can test the region-based display support is with proprietary drivers that nobody but NVIDIA has at this point. Have you considered adding region-based display support to the mdev sample tty driver? I know it sounds ridiculous for a serial device to have a display, but the vfio display region support isn't really tied to the functionality of the base mdev device. We could have it simply display a static test pattern, just so we can test the end to end code path without a dependency on a closed vendor driver. Thanks,

Alex

#24 lore raw
Quoted 11 lines

Hi Gerd,

It's a little bit concerning that the only way we can test the region-based display support is with proprietary drivers that nobody but NVIDIA has at this point. Have you considered adding region-based display support to the mdev sample tty driver? I know it sounds ridiculous for a serial device to have a display, but the vfio display region support isn't really tied to the functionality of the base mdev device. We could have it simply display a static test pattern, just so we can test the end to end code path without a dependency on a closed vendor driver.

Hmm, have to think about that. Some way to change the display content would be nice as you can see whenever display updates are working then.

Maybe the fbcon text rendering code can be used to send the serial console output from the guest to the display ...

cheers,
Gerd

#25 lore raw
Quoted 12 lines · Gerd Hoffmann
Quoted 11 lines

Hi Gerd,

It's a little bit concerning that the only way we can test the region-based display support is with proprietary drivers that nobody but NVIDIA has at this point. Have you considered adding region-based display support to the mdev sample tty driver? I know it sounds ridiculous for a serial device to have a display, but the vfio display region support isn't really tied to the functionality of the base mdev device. We could have it simply display a static test pattern, just so we can test the end to end code path without a dependency on a closed vendor driver.

Quoted 2 lines

Hmm, have to think about that. Some way to change the display content would be nice as you can see whenever display updates are working then.

https://www.kraxel.org/cgit/linux/log/?h=vfio-sample-display

Comes with host mdev driver and guest framebuffer driver.

enjoy,
Gerd

#26 lore raw
Quoted 13 lines · On Mon, 26 Feb 2018 09:35:51 +0100 Gerd Hoffmann <[email protected]> wrote:
Quoted 12 lines · Gerd Hoffmann
Quoted 11 lines

Hi Gerd,

It's a little bit concerning that the only way we can test the region-based display support is with proprietary drivers that nobody but NVIDIA has at this point. Have you considered adding region-based display support to the mdev sample tty driver? I know it sounds ridiculous for a serial device to have a display, but the vfio display region support isn't really tied to the functionality of the base mdev device. We could have it simply display a static test pattern, just so we can test the end to end code path without a dependency on a closed vendor driver.

Quoted 6 lines
Quoted 2 lines

Hmm, have to think about that. Some way to change the display content would be nice as you can see whenever display updates are working then.

https://www.kraxel.org/cgit/linux/log/?h=vfio-sample-display

Comes with host mdev driver and guest framebuffer driver.

Awesome!