* [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR
@ 2018-02-09 7:54 Alexey Kardashevskiy
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 1/4] linux-headers: update to f1517df8701c Alexey Kardashevskiy
` (5 more replies)
0 siblings, 6 replies; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-09 7:54 UTC (permalink / raw)
To: qemu-devel; +Cc: Alexey Kardashevskiy, qemu-ppc, Alex Williamson, David Gibson
Here is my latest patchset to allow mapping of MSIX BAR to the guest
in order to accelerate MMIO on certains devices.
This is based on sha1
008a51b Peter Maydell "Merge remote-tracking branch 'remotes/famz/tags/staging-pull-request' into staging".
Please comment. Thanks.
Changes:
v7:
* split into many patches
* test iova/llsize against pgmask in vfio_listener_region_add/del
* s/vfio_is_cap_present/vfio_has_region_cap/
* added comments here and there
* s/vdev->msix->table_bar/region->nr/
Alexey Kardashevskiy (4):
linux-headers: update to f1517df8701c
vfio/pci: Relax DMA map errors for MMIO regions
vfio-pci: Allow mmap of MSIX BAR
ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices
include/hw/vfio/vfio-common.h | 1 +
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_balloon.h | 3 +-
include/standard-headers/linux/virtio_net.h | 13 +
linux-headers/asm-powerpc/unistd.h | 3 +
linux-headers/asm-s390/unistd.h | 401 +--------------------
linux-headers/linux/psci.h | 3 +
linux-headers/linux/vfio.h | 72 ++++
hw/ppc/spapr.c | 7 +
hw/vfio/common.c | 70 +++-
hw/vfio/pci.c | 22 ++
13 files changed, 220 insertions(+), 417 deletions(-)
--
2.11.0
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Qemu-devel] [PATCH qemu v7 1/4] linux-headers: update to f1517df8701c
2018-02-09 7:54 [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
@ 2018-02-09 7:55 ` Alexey Kardashevskiy
2018-02-10 7:34 ` David Gibson
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions Alexey Kardashevskiy
` (4 subsequent siblings)
5 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-09 7:55 UTC (permalink / raw)
To: qemu-devel; +Cc: Alexey Kardashevskiy, qemu-ppc, Alex Williamson, David Gibson
Update headers against f1517df8701c.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f1517df8701c
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
--
Pulled because of new VFIO_REGION_INFO_CAP_MSIX_MAPPABLE
---
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_balloon.h | 3 +-
include/standard-headers/linux/virtio_net.h | 13 +
| 3 +
| 401 +--------------------
| 3 +
| 72 ++++
9 files changed, 126 insertions(+), 411 deletions(-)
diff --git a/include/standard-headers/linux/input-event-codes.h b/include/standard-headers/linux/input-event-codes.h
index 79841b5..9e6a8ba 100644
--- a/include/standard-headers/linux/input-event-codes.h
+++ b/include/standard-headers/linux/input-event-codes.h
@@ -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 */
diff --git a/include/standard-headers/linux/input.h b/include/standard-headers/linux/input.h
index bc3e6d3..c0bd1ba 100644
--- a/include/standard-headers/linux/input.h
+++ b/include/standard-headers/linux/input.h
@@ -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 (__BITS_PER_LONG != 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;
diff --git a/include/standard-headers/linux/pci_regs.h b/include/standard-headers/linux/pci_regs.h
index 70c2b2a..0c79eac 100644
--- a/include/standard-headers/linux/pci_regs.h
+++ b/include/standard-headers/linux/pci_regs.h
@@ -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 */
diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h
index 9d06ccd..7b0a41b 100644
--- a/include/standard-headers/linux/virtio_balloon.h
+++ b/include/standard-headers/linux/virtio_balloon.h
@@ -52,7 +52,8 @@ struct virtio_balloon_config {
#define VIRTIO_BALLOON_S_MEMFREE 4 /* Total amount of free memory */
#define VIRTIO_BALLOON_S_MEMTOT 5 /* Total amount of memory */
#define VIRTIO_BALLOON_S_AVAIL 6 /* Available memory as in /proc */
-#define VIRTIO_BALLOON_S_NR 7
+#define VIRTIO_BALLOON_S_CACHES 7 /* Disk caches */
+#define VIRTIO_BALLOON_S_NR 8
/*
* Memory statistics structure.
diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h
index 30ff249..e9f255e 100644
--- a/include/standard-headers/linux/virtio_net.h
+++ b/include/standard-headers/linux/virtio_net.h
@@ -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;
/*
--git a/linux-headers/asm-powerpc/unistd.h b/linux-headers/asm-powerpc/unistd.h
index 36abf58..0c08edc 100644
--- a/linux-headers/asm-powerpc/unistd.h
+++ b/linux-headers/asm-powerpc/unistd.h
@@ -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_ */
--git a/linux-headers/asm-s390/unistd.h b/linux-headers/asm-s390/unistd.h
index 99223b8..27b8b21 100644
--- a/linux-headers/asm-s390/unistd.h
+++ b/linux-headers/asm-s390/unistd.h
@@ -8,405 +8,10 @@
#ifndef _ASM_S390_UNISTD_H_
#define _ASM_S390_UNISTD_H_
-/*
- * This file contains the system call numbers.
- */
-
-#define __NR_exit 1
-#define __NR_fork 2
-#define __NR_read 3
-#define __NR_write 4
-#define __NR_open 5
-#define __NR_close 6
-#define __NR_restart_syscall 7
-#define __NR_creat 8
-#define __NR_link 9
-#define __NR_unlink 10
-#define __NR_execve 11
-#define __NR_chdir 12
-#define __NR_mknod 14
-#define __NR_chmod 15
-#define __NR_lseek 19
-#define __NR_getpid 20
-#define __NR_mount 21
-#define __NR_umount 22
-#define __NR_ptrace 26
-#define __NR_alarm 27
-#define __NR_pause 29
-#define __NR_utime 30
-#define __NR_access 33
-#define __NR_nice 34
-#define __NR_sync 36
-#define __NR_kill 37
-#define __NR_rename 38
-#define __NR_mkdir 39
-#define __NR_rmdir 40
-#define __NR_dup 41
-#define __NR_pipe 42
-#define __NR_times 43
-#define __NR_brk 45
-#define __NR_signal 48
-#define __NR_acct 51
-#define __NR_umount2 52
-#define __NR_ioctl 54
-#define __NR_fcntl 55
-#define __NR_setpgid 57
-#define __NR_umask 60
-#define __NR_chroot 61
-#define __NR_ustat 62
-#define __NR_dup2 63
-#define __NR_getppid 64
-#define __NR_getpgrp 65
-#define __NR_setsid 66
-#define __NR_sigaction 67
-#define __NR_sigsuspend 72
-#define __NR_sigpending 73
-#define __NR_sethostname 74
-#define __NR_setrlimit 75
-#define __NR_getrusage 77
-#define __NR_gettimeofday 78
-#define __NR_settimeofday 79
-#define __NR_symlink 83
-#define __NR_readlink 85
-#define __NR_uselib 86
-#define __NR_swapon 87
-#define __NR_reboot 88
-#define __NR_readdir 89
-#define __NR_mmap 90
-#define __NR_munmap 91
-#define __NR_truncate 92
-#define __NR_ftruncate 93
-#define __NR_fchmod 94
-#define __NR_getpriority 96
-#define __NR_setpriority 97
-#define __NR_statfs 99
-#define __NR_fstatfs 100
-#define __NR_socketcall 102
-#define __NR_syslog 103
-#define __NR_setitimer 104
-#define __NR_getitimer 105
-#define __NR_stat 106
-#define __NR_lstat 107
-#define __NR_fstat 108
-#define __NR_lookup_dcookie 110
-#define __NR_vhangup 111
-#define __NR_idle 112
-#define __NR_wait4 114
-#define __NR_swapoff 115
-#define __NR_sysinfo 116
-#define __NR_ipc 117
-#define __NR_fsync 118
-#define __NR_sigreturn 119
-#define __NR_clone 120
-#define __NR_setdomainname 121
-#define __NR_uname 122
-#define __NR_adjtimex 124
-#define __NR_mprotect 125
-#define __NR_sigprocmask 126
-#define __NR_create_module 127
-#define __NR_init_module 128
-#define __NR_delete_module 129
-#define __NR_get_kernel_syms 130
-#define __NR_quotactl 131
-#define __NR_getpgid 132
-#define __NR_fchdir 133
-#define __NR_bdflush 134
-#define __NR_sysfs 135
-#define __NR_personality 136
-#define __NR_afs_syscall 137 /* Syscall for Andrew File System */
-#define __NR_getdents 141
-#define __NR_flock 143
-#define __NR_msync 144
-#define __NR_readv 145
-#define __NR_writev 146
-#define __NR_getsid 147
-#define __NR_fdatasync 148
-#define __NR__sysctl 149
-#define __NR_mlock 150
-#define __NR_munlock 151
-#define __NR_mlockall 152
-#define __NR_munlockall 153
-#define __NR_sched_setparam 154
-#define __NR_sched_getparam 155
-#define __NR_sched_setscheduler 156
-#define __NR_sched_getscheduler 157
-#define __NR_sched_yield 158
-#define __NR_sched_get_priority_max 159
-#define __NR_sched_get_priority_min 160
-#define __NR_sched_rr_get_interval 161
-#define __NR_nanosleep 162
-#define __NR_mremap 163
-#define __NR_query_module 167
-#define __NR_poll 168
-#define __NR_nfsservctl 169
-#define __NR_prctl 172
-#define __NR_rt_sigreturn 173
-#define __NR_rt_sigaction 174
-#define __NR_rt_sigprocmask 175
-#define __NR_rt_sigpending 176
-#define __NR_rt_sigtimedwait 177
-#define __NR_rt_sigqueueinfo 178
-#define __NR_rt_sigsuspend 179
-#define __NR_pread64 180
-#define __NR_pwrite64 181
-#define __NR_getcwd 183
-#define __NR_capget 184
-#define __NR_capset 185
-#define __NR_sigaltstack 186
-#define __NR_sendfile 187
-#define __NR_getpmsg 188
-#define __NR_putpmsg 189
-#define __NR_vfork 190
-#define __NR_pivot_root 217
-#define __NR_mincore 218
-#define __NR_madvise 219
-#define __NR_getdents64 220
-#define __NR_readahead 222
-#define __NR_setxattr 224
-#define __NR_lsetxattr 225
-#define __NR_fsetxattr 226
-#define __NR_getxattr 227
-#define __NR_lgetxattr 228
-#define __NR_fgetxattr 229
-#define __NR_listxattr 230
-#define __NR_llistxattr 231
-#define __NR_flistxattr 232
-#define __NR_removexattr 233
-#define __NR_lremovexattr 234
-#define __NR_fremovexattr 235
-#define __NR_gettid 236
-#define __NR_tkill 237
-#define __NR_futex 238
-#define __NR_sched_setaffinity 239
-#define __NR_sched_getaffinity 240
-#define __NR_tgkill 241
-/* Number 242 is reserved for tux */
-#define __NR_io_setup 243
-#define __NR_io_destroy 244
-#define __NR_io_getevents 245
-#define __NR_io_submit 246
-#define __NR_io_cancel 247
-#define __NR_exit_group 248
-#define __NR_epoll_create 249
-#define __NR_epoll_ctl 250
-#define __NR_epoll_wait 251
-#define __NR_set_tid_address 252
-#define __NR_fadvise64 253
-#define __NR_timer_create 254
-#define __NR_timer_settime 255
-#define __NR_timer_gettime 256
-#define __NR_timer_getoverrun 257
-#define __NR_timer_delete 258
-#define __NR_clock_settime 259
-#define __NR_clock_gettime 260
-#define __NR_clock_getres 261
-#define __NR_clock_nanosleep 262
-/* Number 263 is reserved for vserver */
-#define __NR_statfs64 265
-#define __NR_fstatfs64 266
-#define __NR_remap_file_pages 267
-#define __NR_mbind 268
-#define __NR_get_mempolicy 269
-#define __NR_set_mempolicy 270
-#define __NR_mq_open 271
-#define __NR_mq_unlink 272
-#define __NR_mq_timedsend 273
-#define __NR_mq_timedreceive 274
-#define __NR_mq_notify 275
-#define __NR_mq_getsetattr 276
-#define __NR_kexec_load 277
-#define __NR_add_key 278
-#define __NR_request_key 279
-#define __NR_keyctl 280
-#define __NR_waitid 281
-#define __NR_ioprio_set 282
-#define __NR_ioprio_get 283
-#define __NR_inotify_init 284
-#define __NR_inotify_add_watch 285
-#define __NR_inotify_rm_watch 286
-#define __NR_migrate_pages 287
-#define __NR_openat 288
-#define __NR_mkdirat 289
-#define __NR_mknodat 290
-#define __NR_fchownat 291
-#define __NR_futimesat 292
-#define __NR_unlinkat 294
-#define __NR_renameat 295
-#define __NR_linkat 296
-#define __NR_symlinkat 297
-#define __NR_readlinkat 298
-#define __NR_fchmodat 299
-#define __NR_faccessat 300
-#define __NR_pselect6 301
-#define __NR_ppoll 302
-#define __NR_unshare 303
-#define __NR_set_robust_list 304
-#define __NR_get_robust_list 305
-#define __NR_splice 306
-#define __NR_sync_file_range 307
-#define __NR_tee 308
-#define __NR_vmsplice 309
-#define __NR_move_pages 310
-#define __NR_getcpu 311
-#define __NR_epoll_pwait 312
-#define __NR_utimes 313
-#define __NR_fallocate 314
-#define __NR_utimensat 315
-#define __NR_signalfd 316
-#define __NR_timerfd 317
-#define __NR_eventfd 318
-#define __NR_timerfd_create 319
-#define __NR_timerfd_settime 320
-#define __NR_timerfd_gettime 321
-#define __NR_signalfd4 322
-#define __NR_eventfd2 323
-#define __NR_inotify_init1 324
-#define __NR_pipe2 325
-#define __NR_dup3 326
-#define __NR_epoll_create1 327
-#define __NR_preadv 328
-#define __NR_pwritev 329
-#define __NR_rt_tgsigqueueinfo 330
-#define __NR_perf_event_open 331
-#define __NR_fanotify_init 332
-#define __NR_fanotify_mark 333
-#define __NR_prlimit64 334
-#define __NR_name_to_handle_at 335
-#define __NR_open_by_handle_at 336
-#define __NR_clock_adjtime 337
-#define __NR_syncfs 338
-#define __NR_setns 339
-#define __NR_process_vm_readv 340
-#define __NR_process_vm_writev 341
-#define __NR_s390_runtime_instr 342
-#define __NR_kcmp 343
-#define __NR_finit_module 344
-#define __NR_sched_setattr 345
-#define __NR_sched_getattr 346
-#define __NR_renameat2 347
-#define __NR_seccomp 348
-#define __NR_getrandom 349
-#define __NR_memfd_create 350
-#define __NR_bpf 351
-#define __NR_s390_pci_mmio_write 352
-#define __NR_s390_pci_mmio_read 353
-#define __NR_execveat 354
-#define __NR_userfaultfd 355
-#define __NR_membarrier 356
-#define __NR_recvmmsg 357
-#define __NR_sendmmsg 358
-#define __NR_socket 359
-#define __NR_socketpair 360
-#define __NR_bind 361
-#define __NR_connect 362
-#define __NR_listen 363
-#define __NR_accept4 364
-#define __NR_getsockopt 365
-#define __NR_setsockopt 366
-#define __NR_getsockname 367
-#define __NR_getpeername 368
-#define __NR_sendto 369
-#define __NR_sendmsg 370
-#define __NR_recvfrom 371
-#define __NR_recvmsg 372
-#define __NR_shutdown 373
-#define __NR_mlock2 374
-#define __NR_copy_file_range 375
-#define __NR_preadv2 376
-#define __NR_pwritev2 377
-#define __NR_s390_guarded_storage 378
-#define __NR_statx 379
-#define __NR_s390_sthyi 380
-#define NR_syscalls 381
-
-/*
- * There are some system calls that are not present on 64 bit, some
- * have a different name although they do the same (e.g. __NR_chown32
- * is __NR_chown on 64 bit).
- */
-#ifndef __s390x__
-
-#define __NR_time 13
-#define __NR_lchown 16
-#define __NR_setuid 23
-#define __NR_getuid 24
-#define __NR_stime 25
-#define __NR_setgid 46
-#define __NR_getgid 47
-#define __NR_geteuid 49
-#define __NR_getegid 50
-#define __NR_setreuid 70
-#define __NR_setregid 71
-#define __NR_getrlimit 76
-#define __NR_getgroups 80
-#define __NR_setgroups 81
-#define __NR_fchown 95
-#define __NR_ioperm 101
-#define __NR_setfsuid 138
-#define __NR_setfsgid 139
-#define __NR__llseek 140
-#define __NR__newselect 142
-#define __NR_setresuid 164
-#define __NR_getresuid 165
-#define __NR_setresgid 170
-#define __NR_getresgid 171
-#define __NR_chown 182
-#define __NR_ugetrlimit 191 /* SuS compliant getrlimit */
-#define __NR_mmap2 192
-#define __NR_truncate64 193
-#define __NR_ftruncate64 194
-#define __NR_stat64 195
-#define __NR_lstat64 196
-#define __NR_fstat64 197
-#define __NR_lchown32 198
-#define __NR_getuid32 199
-#define __NR_getgid32 200
-#define __NR_geteuid32 201
-#define __NR_getegid32 202
-#define __NR_setreuid32 203
-#define __NR_setregid32 204
-#define __NR_getgroups32 205
-#define __NR_setgroups32 206
-#define __NR_fchown32 207
-#define __NR_setresuid32 208
-#define __NR_getresuid32 209
-#define __NR_setresgid32 210
-#define __NR_getresgid32 211
-#define __NR_chown32 212
-#define __NR_setuid32 213
-#define __NR_setgid32 214
-#define __NR_setfsuid32 215
-#define __NR_setfsgid32 216
-#define __NR_fcntl64 221
-#define __NR_sendfile64 223
-#define __NR_fadvise64_64 264
-#define __NR_fstatat64 293
-
+#ifdef __s390x__
+#include <asm/unistd_64.h>
#else
-
-#define __NR_select 142
-#define __NR_getrlimit 191 /* SuS compliant getrlimit */
-#define __NR_lchown 198
-#define __NR_getuid 199
-#define __NR_getgid 200
-#define __NR_geteuid 201
-#define __NR_getegid 202
-#define __NR_setreuid 203
-#define __NR_setregid 204
-#define __NR_getgroups 205
-#define __NR_setgroups 206
-#define __NR_fchown 207
-#define __NR_setresuid 208
-#define __NR_getresuid 209
-#define __NR_setresgid 210
-#define __NR_getresgid 211
-#define __NR_chown 212
-#define __NR_setuid 213
-#define __NR_setgid 214
-#define __NR_setfsuid 215
-#define __NR_setfsgid 216
-#define __NR_newfstatat 293
-
+#include <asm/unistd_32.h>
#endif
#endif /* _ASM_S390_UNISTD_H_ */
--git a/linux-headers/linux/psci.h b/linux-headers/linux/psci.h
index ccd1773..3905492 100644
--- a/linux-headers/linux/psci.h
+++ b/linux-headers/linux/psci.h
@@ -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
--git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index 4312e96..3a0a305 100644
--- a/linux-headers/linux/vfio.h
+++ b/linux-headers/linux/vfio.h
@@ -301,6 +301,16 @@ struct vfio_region_info_cap_type {
#define VFIO_REGION_SUBTYPE_INTEL_IGD_HOST_CFG (2)
#define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG (3)
+/*
+ * The MSIX mappable capability informs that MSIX data of a BAR can be mmapped
+ * which allows direct access to non-MSIX registers which happened to be within
+ * the same system page.
+ *
+ * Even though the userspace gets direct access to the MSIX data, the existing
+ * VFIO_DEVICE_SET_IRQS interface must still be used for MSIX configuration.
+ */
+#define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE 3
+
/**
* VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,
* struct vfio_irq_info)
@@ -503,6 +513,68 @@ struct vfio_pci_hot_reset {
#define VFIO_DEVICE_PCI_HOT_RESET _IO(VFIO_TYPE, VFIO_BASE + 13)
+/**
+ * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
+ * struct vfio_device_query_gfx_plane)
+ *
+ * Set the drm_plane_type and flags, then retrieve the gfx plane info.
+ *
+ * flags supported:
+ * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_DMABUF are set
+ * to ask if the mdev supports dma-buf. 0 on support, -EINVAL on no
+ * support for dma-buf.
+ * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_REGION are set
+ * to ask if the mdev supports region. 0 on support, -EINVAL on no
+ * support for region.
+ * - VFIO_GFX_PLANE_TYPE_DMABUF or VFIO_GFX_PLANE_TYPE_REGION is set
+ * with each call to query the plane info.
+ * - Others are invalid and return -EINVAL.
+ *
+ * Note:
+ * 1. Plane could be disabled by guest. In that case, success will be
+ * returned with zero-initialized drm_format, size, width and height
+ * fields.
+ * 2. x_hot/y_hot is set to 0xFFFFFFFF if no hotspot information available
+ *
+ * Return: 0 on success, -errno on other failure.
+ */
+struct vfio_device_gfx_plane_info {
+ __u32 argsz;
+ __u32 flags;
+#define VFIO_GFX_PLANE_TYPE_PROBE (1 << 0)
+#define VFIO_GFX_PLANE_TYPE_DMABUF (1 << 1)
+#define VFIO_GFX_PLANE_TYPE_REGION (1 << 2)
+ /* in */
+ __u32 drm_plane_type; /* type of plane: DRM_PLANE_TYPE_* */
+ /* out */
+ __u32 drm_format; /* drm format of plane */
+ __u64 drm_format_mod; /* tiled mode */
+ __u32 width; /* width of plane */
+ __u32 height; /* height of plane */
+ __u32 stride; /* stride of plane */
+ __u32 size; /* size of plane in bytes, align on page*/
+ __u32 x_pos; /* horizontal position of cursor plane */
+ __u32 y_pos; /* vertical position of cursor plane*/
+ __u32 x_hot; /* horizontal position of cursor hotspot */
+ __u32 y_hot; /* vertical position of cursor hotspot */
+ union {
+ __u32 region_index; /* region index */
+ __u32 dmabuf_id; /* dma-buf id */
+ };
+};
+
+#define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)
+
+/**
+ * VFIO_DEVICE_GET_GFX_DMABUF - _IOW(VFIO_TYPE, VFIO_BASE + 15, __u32)
+ *
+ * Return a new dma-buf file descriptor for an exposed guest framebuffer
+ * described by the provided dmabuf_id. The dmabuf_id is returned from VFIO_
+ * DEVICE_QUERY_GFX_PLANE as a token of the exposed guest framebuffer.
+ */
+
+#define VFIO_DEVICE_GET_GFX_DMABUF _IO(VFIO_TYPE, VFIO_BASE + 15)
+
/* -------- API for Type1 VFIO IOMMU -------- */
/**
--
2.11.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-09 7:54 [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 1/4] linux-headers: update to f1517df8701c Alexey Kardashevskiy
@ 2018-02-09 7:55 ` Alexey Kardashevskiy
2018-02-12 5:19 ` David Gibson
2018-03-19 20:49 ` Auger Eric
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 3/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
` (3 subsequent siblings)
5 siblings, 2 replies; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-09 7:55 UTC (permalink / raw)
To: qemu-devel; +Cc: Alexey Kardashevskiy, qemu-ppc, Alex Williamson, David Gibson
At the moment if vfio_memory_listener is registered in the system memory
address space, it maps/unmaps every RAM memory region for DMA.
It expects system page size aligned memory sections so vfio_dma_map
would not fail and so far this has been the case. A mapping failure
would be fatal. A side effect of such behavior is that some MMIO pages
would not be mapped silently.
However we are going to change MSIX BAR handling so we will end having
non-aligned sections in vfio_memory_listener (more details is in
the next patch) and vfio_dma_map will exit QEMU.
In order to avoid fatal failures on what previously was not a failure and
was just silently ignored, this checks the section alignment to
the smallest supported IOMMU page size and prints an error if not aligned;
it also prints an error if vfio_dma_map failed despite the page size check.
Both errors are not fatal; only MMIO RAM regions are checked
(aka "RAM device" regions).
If the amount of errors printed is overwhelming, the MSIX relocation
could be used to avoid excessive error output.
This is unlikely to cause any behavioral change.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
hw/vfio/common.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index f895e3c..736f271 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -544,18 +544,40 @@ static void vfio_listener_region_add(MemoryListener *listener,
llsize = int128_sub(llend, int128_make64(iova));
+ if (memory_region_is_ram_device(section->mr)) {
+ hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
+
+ if ((iova & pgmask) || (llsize & pgmask)) {
+ error_report("Region 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx
+ " is not aligned to 0x%"HWADDR_PRIx
+ " and cannot be mapped for DMA",
+ section->offset_within_region,
+ int128_getlo(section->size),
+ pgmask + 1);
+ return;
+ }
+ }
+
ret = vfio_dma_map(container, iova, int128_get64(llsize),
vaddr, section->readonly);
if (ret) {
error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
"0x%"HWADDR_PRIx", %p) = %d (%m)",
container, iova, int128_get64(llsize), vaddr, ret);
+ if (memory_region_is_ram_device(section->mr)) {
+ /* Allow unexpected mappings not to be fatal for RAM devices */
+ return;
+ }
goto fail;
}
return;
fail:
+ if (memory_region_is_ram_device(section->mr)) {
+ error_report("failed to vfio_dma_map. pci p2p may not work");
+ return;
+ }
/*
* On the initfn path, store the first error in the container so we
* can gracefully fail. Runtime, there's not much we can do other
@@ -577,6 +599,7 @@ static void vfio_listener_region_del(MemoryListener *listener,
hwaddr iova, end;
Int128 llend, llsize;
int ret;
+ bool try_unmap = true;
if (vfio_listener_skipped_section(section)) {
trace_vfio_listener_region_del_skip(
@@ -629,13 +652,33 @@ static void vfio_listener_region_del(MemoryListener *listener,
trace_vfio_listener_region_del(iova, end);
- ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
+ if (memory_region_is_ram_device(section->mr)) {
+ hwaddr pgmask;
+ VFIOHostDMAWindow *hostwin;
+ bool hostwin_found = false;
+
+ QLIST_FOREACH(hostwin, &container->hostwin_list, hostwin_next) {
+ if (hostwin->min_iova <= iova && end <= hostwin->max_iova) {
+ hostwin_found = true;
+ break;
+ }
+ }
+ assert(hostwin_found); /* or region_add() would have failed */
+
+ pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
+ try_unmap = !((iova & pgmask) || (llsize & pgmask));
+ }
+
+ if (try_unmap) {
+ ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
+ if (ret) {
+ error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
+ "0x%"HWADDR_PRIx") = %d (%m)",
+ container, iova, int128_get64(llsize), ret);
+ }
+ }
+
memory_region_unref(section->mr);
- if (ret) {
- error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
- "0x%"HWADDR_PRIx") = %d (%m)",
- container, iova, int128_get64(llsize), ret);
- }
if (container->iommu_type == VFIO_SPAPR_TCE_v2_IOMMU) {
vfio_spapr_remove_window(container,
--
2.11.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [Qemu-devel] [PATCH qemu v7 3/4] vfio-pci: Allow mmap of MSIX BAR
2018-02-09 7:54 [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 1/4] linux-headers: update to f1517df8701c Alexey Kardashevskiy
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions Alexey Kardashevskiy
@ 2018-02-09 7:55 ` Alexey Kardashevskiy
2018-02-13 5:39 ` David Gibson
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 4/4] ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices Alexey Kardashevskiy
` (2 subsequent siblings)
5 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-09 7:55 UTC (permalink / raw)
To: qemu-devel; +Cc: Alexey Kardashevskiy, qemu-ppc, Alex Williamson, David Gibson
At the moment we unconditionally avoid mapping MSIX data of a BAR and
emulate MSIX table in QEMU. However it is 1) not always necessary as
a platform may prodive a paravirt interface for MSIX configuration;
2) can affect the speed of MMIO access by emulating them in QEMU when
frequently accessed registers share same system page with MSIX data,
this is particularly a problem for systems with the page size bigger
than 4KB.
A new capability - VFIO_REGION_INFO_CAP_MSIX_MAPPABLE - has been added
to the kernel [1] which tells the userspace that mapping of the MSIX data
is possible now. This makes use of it so from now on QEMU tries mapping
the entire BAR as a whole and emulate MSIX on top of that.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a32295c612c57990d17fb0f41e7134394b2f35f6
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v7:
* test iova/llsize against pgmask in vfio_listener_region_add/del
* s/vfio_is_cap_present/vfio_has_region_cap/
* added comments here and there
* s/vdev->msix->table_bar/region-nr/
---
include/hw/vfio/vfio-common.h | 1 +
hw/vfio/common.c | 15 +++++++++++++++
hw/vfio/pci.c | 9 +++++++++
3 files changed, 25 insertions(+)
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index f3a2ac9..42dd2b0 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -171,6 +171,7 @@ int vfio_get_region_info(VFIODevice *vbasedev, int index,
struct vfio_region_info **info);
int vfio_get_dev_region_info(VFIODevice *vbasedev, uint32_t type,
uint32_t subtype, struct vfio_region_info **info);
+bool vfio_has_region_cap(VFIODevice *vbasedev, int region, uint16_t cap_type);
#endif
extern const MemoryListener vfio_prereg_listener;
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 736f271..b99ae77 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1464,6 +1464,21 @@ int vfio_get_dev_region_info(VFIODevice *vbasedev, uint32_t type,
return -ENODEV;
}
+bool vfio_has_region_cap(VFIODevice *vbasedev, int region, uint16_t cap_type)
+{
+ struct vfio_region_info *info = NULL;
+ bool ret = false;
+
+ if (!vfio_get_region_info(vbasedev, region, &info)) {
+ if (vfio_get_region_info_cap(info, cap_type)) {
+ ret = true;
+ }
+ g_free(info);
+ }
+
+ return ret;
+}
+
/*
* Interfaces for IBM EEH (Enhanced Error Handling)
*/
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 879510c..ae9098d 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1294,6 +1294,15 @@ static void vfio_pci_fixup_msix_region(VFIOPCIDevice *vdev)
VFIORegion *region = &vdev->bars[vdev->msix->table_bar].region;
/*
+ * If the host driver allows mapping of a MSIX data, we are going to
+ * do map the entire BAR and emulate MSIX table on top of that.
+ */
+ if (vfio_has_region_cap(&vdev->vbasedev, region->nr,
+ VFIO_REGION_INFO_CAP_MSIX_MAPPABLE)) {
+ return;
+ }
+
+ /*
* We expect to find a single mmap covering the whole BAR, anything else
* means it's either unsupported or already setup.
*/
--
2.11.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [Qemu-devel] [PATCH qemu v7 4/4] ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices
2018-02-09 7:54 [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
` (2 preceding siblings ...)
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 3/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
@ 2018-02-09 7:55 ` Alexey Kardashevskiy
2018-02-13 5:43 ` David Gibson
2018-02-09 8:04 ` [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR no-reply
2018-02-09 8:05 ` no-reply
5 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-09 7:55 UTC (permalink / raw)
To: qemu-devel; +Cc: Alexey Kardashevskiy, qemu-ppc, Alex Williamson, David Gibson
This adds a possibility for the platform to tell VFIO not to emulate MSIX
so MMIO memory regions do not get split into chunks in flatview and
the entire page can be registered as a KVM memory slot and make direct
MMIO access possible for the guest.
This enables the entire MSIX BAR mapping to the guest for the pseries
platform in order to achieve the maximum MMIO preformance for certain
devices.
Tested on:
LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Need to split this in two?
---
hw/ppc/spapr.c | 7 +++++++
hw/vfio/pci.c | 13 +++++++++++++
2 files changed, 20 insertions(+)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index eb3e1a7..14d8ecb 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2855,6 +2855,11 @@ static void spapr_set_modern_hotplug_events(Object *obj, bool value,
spapr->use_hotplug_event_source = value;
}
+static bool spapr_get_msix_emulation(Object *obj, Error **errp)
+{
+ return true;
+}
+
static char *spapr_get_resize_hpt(Object *obj, Error **errp)
{
sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
@@ -2936,6 +2941,8 @@ static void spapr_instance_init(Object *obj)
object_property_set_description(obj, "vsmt",
"Virtual SMT: KVM behaves as if this were"
" the host's SMT mode", &error_abort);
+ object_property_add_bool(obj, "vfio-no-msix-emulation",
+ spapr_get_msix_emulation, NULL, NULL);
}
static void spapr_machine_finalizefn(Object *obj)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index ae9098d..4a03085 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1580,6 +1580,19 @@ static int vfio_msix_setup(VFIOPCIDevice *vdev, int pos, Error **errp)
*/
memory_region_set_enabled(&vdev->pdev.msix_pba_mmio, false);
+ /*
+ * The emulated machine may provide a paravirt interface for MSIX setup
+ * so it is not strictly necessary to emulate MSIX here. This becomes
+ * helpful when frequently accessed MMIO registers are located in
+ * subpages adjacent to the MSIX table but the MSIX data containing page
+ * cannot be mapped because of a host page size bigger than the MSIX table
+ * alignment.
+ */
+ if (object_property_get_bool(OBJECT(qdev_get_machine()),
+ "vfio-no-msix-emulation", NULL)) {
+ memory_region_set_enabled(&vdev->pdev.msix_table_mmio, false);
+ }
+
return 0;
}
--
2.11.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR
2018-02-09 7:54 [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
` (3 preceding siblings ...)
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 4/4] ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices Alexey Kardashevskiy
@ 2018-02-09 8:04 ` no-reply
2018-02-09 8:05 ` no-reply
5 siblings, 0 replies; 34+ messages in thread
From: no-reply @ 2018-02-09 8:04 UTC (permalink / raw)
To: aik; +Cc: famz, qemu-devel, alex.williamson, qemu-ppc, david
Hi,
This series failed build test on s390x host. Please find the details below.
Type: series
Message-id: 20180209075503.16996-1-aik@ozlabs.ru
Subject: [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
echo "=== ENV ==="
env
echo "=== PACKAGES ==="
rpm -qa
echo "=== TEST BEGIN ==="
CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
echo -n "Using CC: "
realpath $CC
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag] patchew/20180209075503.16996-1-aik@ozlabs.ru -> patchew/20180209075503.16996-1-aik@ozlabs.ru
Switched to a new branch 'test'
364588cdea ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices
b35d106f4a vfio-pci: Allow mmap of MSIX BAR
7144306422 vfio/pci: Relax DMA map errors for MMIO regions
8b136cea18 linux-headers: update to f1517df8701c
=== OUTPUT BEGIN ===
=== ENV ===
LANG=en_US.UTF-8
XDG_SESSION_ID=48386
USER=fam
PWD=/var/tmp/patchew-tester-tmp-oqq3slb3/src
HOME=/home/fam
SHELL=/bin/sh
SHLVL=2
PATCHEW=/home/fam/patchew/patchew-cli -s http://patchew.org --nodebug
LOGNAME=fam
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1012/bus
XDG_RUNTIME_DIR=/run/user/1012
PATH=/usr/bin:/bin
_=/usr/bin/env
=== PACKAGES ===
gpg-pubkey-873529b8-54e386ff
glibc-debuginfo-common-2.24-10.fc25.s390x
fedora-release-26-1.noarch
dejavu-sans-mono-fonts-2.35-4.fc26.noarch
xemacs-filesystem-21.5.34-22.20170124hgf412e9f093d4.fc26.noarch
bash-4.4.12-7.fc26.s390x
freetype-2.7.1-9.fc26.s390x
libSM-1.2.2-5.fc26.s390x
libmpc-1.0.2-6.fc26.s390x
libaio-0.3.110-7.fc26.s390x
libverto-0.2.6-7.fc26.s390x
perl-Scalar-List-Utils-1.48-1.fc26.s390x
iptables-libs-1.6.1-2.fc26.s390x
perl-threads-shared-1.57-1.fc26.s390x
p11-kit-trust-0.23.9-2.fc26.s390x
tcl-8.6.6-2.fc26.s390x
libxshmfence-1.2-4.fc26.s390x
expect-5.45-23.fc26.s390x
perl-Thread-Queue-3.12-1.fc26.noarch
perl-encoding-2.19-6.fc26.s390x
keyutils-1.5.10-1.fc26.s390x
gmp-devel-6.1.2-4.fc26.s390x
enchant-1.6.0-16.fc26.s390x
net-snmp-libs-5.7.3-17.fc26.s390x
python-gobject-base-3.24.1-1.fc26.s390x
python3-distro-1.0.3-1.fc26.noarch
python3-enchant-1.6.10-1.fc26.noarch
python-lockfile-0.11.0-6.fc26.noarch
python2-pyparsing-2.1.10-3.fc26.noarch
python2-lxml-4.1.1-1.fc26.s390x
librados2-10.2.7-2.fc26.s390x
trousers-lib-0.3.13-7.fc26.s390x
libpaper-1.1.24-14.fc26.s390x
libdatrie-0.2.9-4.fc26.s390x
libsoup-2.58.2-1.fc26.s390x
passwd-0.79-9.fc26.s390x
bind99-libs-9.9.10-3.P3.fc26.s390x
python3-rpm-4.13.0.2-1.fc26.s390x
mock-core-configs-27.4-1.fc26.noarch
systemd-233-7.fc26.s390x
virglrenderer-0.6.0-1.20170210git76b3da97b.fc26.s390x
s390utils-ziomon-1.36.1-3.fc26.s390x
s390utils-osasnmpd-1.36.1-3.fc26.s390x
libXrandr-1.5.1-2.fc26.s390x
libglvnd-glx-1.0.0-1.fc26.s390x
texlive-ifxetex-svn19685.0.5-33.fc26.2.noarch
texlive-psnfss-svn33946.9.2a-33.fc26.2.noarch
texlive-dvipdfmx-def-svn40328-33.fc26.2.noarch
texlive-natbib-svn20668.8.31b-33.fc26.2.noarch
texlive-xdvi-bin-svn40750-33.20160520.fc26.2.s390x
texlive-cm-svn32865.0-33.fc26.2.noarch
texlive-beton-svn15878.0-33.fc26.2.noarch
texlive-fpl-svn15878.1.002-33.fc26.2.noarch
texlive-mflogo-svn38628-33.fc26.2.noarch
texlive-texlive-docindex-svn41430-33.fc26.2.noarch
texlive-luaotfload-bin-svn34647.0-33.20160520.fc26.2.noarch
texlive-koma-script-svn41508-33.fc26.2.noarch
texlive-pst-tree-svn24142.1.12-33.fc26.2.noarch
texlive-breqn-svn38099.0.98d-33.fc26.2.noarch
texlive-xetex-svn41438-33.fc26.2.noarch
gstreamer1-plugins-bad-free-1.12.3-1.fc26.s390x
xorg-x11-font-utils-7.5-33.fc26.s390x
ghostscript-fonts-5.50-36.fc26.noarch
libXext-devel-1.3.3-5.fc26.s390x
libusbx-devel-1.0.21-2.fc26.s390x
libglvnd-devel-1.0.0-1.fc26.s390x
emacs-25.3-3.fc26.s390x
alsa-lib-devel-1.1.4.1-1.fc26.s390x
kbd-2.0.4-2.fc26.s390x
dconf-0.26.0-2.fc26.s390x
ccache-3.3.4-1.fc26.s390x
glibc-static-2.25-12.fc26.s390x
mc-4.8.19-5.fc26.s390x
doxygen-1.8.13-9.fc26.s390x
dpkg-1.18.24-1.fc26.s390x
libtdb-1.3.13-1.fc26.s390x
python2-pynacl-1.1.1-1.fc26.s390x
nss-sysinit-3.34.0-1.0.fc26.s390x
kernel-4.13.16-202.fc26.s390x
perl-Filter-1.58-1.fc26.s390x
python2-pip-9.0.1-11.fc26.noarch
dnf-2.7.5-2.fc26.noarch
pcre2-utf16-10.23-11.fc26.s390x
glusterfs-devel-3.10.8-1.fc26.s390x
sssd-common-1.16.0-4.fc26.s390x
python2-sssdconfig-1.16.0-4.fc26.noarch
acpica-tools-20171110-1.fc26.s390x
glibc-debuginfo-2.24-10.fc25.s390x
fedora-repos-26-1.noarch
dejavu-fonts-common-2.35-4.fc26.noarch
bind99-license-9.9.10-3.P3.fc26.noarch
ncurses-libs-6.0-8.20170212.fc26.s390x
libpng-1.6.28-2.fc26.s390x
libICE-1.0.9-9.fc26.s390x
kmod-24-1.fc26.s390x
libseccomp-2.3.2-1.fc26.s390x
perl-Text-ParseWords-3.30-366.fc26.noarch
libtool-ltdl-2.4.6-17.fc26.s390x
perl-threads-2.16-1.fc26.s390x
libselinux-utils-2.6-7.fc26.s390x
userspace-rcu-0.9.3-2.fc26.s390x
libXfont-1.5.2-5.fc26.s390x
perl-Class-Inspector-1.31-3.fc26.noarch
perl-open-1.10-395.fc26.noarch
keyutils-libs-devel-1.5.10-1.fc26.s390x
isl-0.16.1-1.fc26.s390x
libsecret-0.18.5-3.fc26.s390x
compat-openssl10-1.0.2m-1.fc26.s390x
python3-iniparse-0.4-24.fc26.noarch
python3-dateutil-2.6.0-3.fc26.noarch
python3-firewall-0.4.4.5-1.fc26.noarch
python-enum34-1.1.6-1.fc26.noarch
python2-pygments-2.2.0-7.fc26.noarch
python2-dockerfile-parse-0.0.7-1.fc26.noarch
perl-Net-SSLeay-1.81-1.fc26.s390x
hostname-3.18-2.fc26.s390x
libtirpc-1.0.2-0.fc26.s390x
rpm-build-libs-4.13.0.2-1.fc26.s390x
libutempter-1.1.6-9.fc26.s390x
systemd-pam-233-7.fc26.s390x
pcre-utf16-8.41-3.fc26.s390x
libXinerama-1.1.3-7.fc26.s390x
mesa-libGL-17.2.4-2.fc26.s390x
texlive-amsfonts-svn29208.3.04-33.fc26.2.noarch
texlive-caption-svn41409-33.fc26.2.noarch
texlive-enumitem-svn24146.3.5.2-33.fc26.2.noarch
texlive-pdftex-def-svn22653.0.06d-33.fc26.2.noarch
texlive-xdvi-svn40768-33.fc26.2.noarch
texlive-courier-svn35058.0-33.fc26.2.noarch
texlive-charter-svn15878.0-33.fc26.2.noarch
texlive-graphics-def-svn41879-33.fc26.2.noarch
texlive-mfnfss-svn19410.0-33.fc26.2.noarch
texlive-texlive-en-svn41185-33.fc26.2.noarch
texlive-ifplatform-svn21156.0.4-33.fc26.2.noarch
texlive-ms-svn29849.0-33.fc26.2.noarch
texlive-pst-tools-svn34067.0.05-33.fc26.2.noarch
texlive-powerdot-svn38984-33.fc26.2.noarch
texlive-xetexconfig-svn41133-33.fc26.2.noarch
libvdpau-1.1.1-4.fc26.s390x
zlib-devel-1.2.11-2.fc26.s390x
gdk-pixbuf2-devel-2.36.9-1.fc26.s390x
libX11-devel-1.6.5-2.fc26.s390x
libtasn1-devel-4.12-1.fc26.s390x
libglvnd-core-devel-1.0.0-1.fc26.s390x
SDL2-devel-2.0.7-2.fc26.s390x
webkitgtk3-2.4.11-5.fc26.s390x
grubby-8.40-4.fc26.s390x
uboot-tools-2017.05-4.fc26.s390x
cracklib-dicts-2.9.6-5.fc26.s390x
texinfo-6.3-3.fc26.s390x
time-1.7-52.fc26.s390x
python2-deltarpm-3.6-19.fc26.s390x
nss-3.34.0-1.0.fc26.s390x
webkitgtk4-2.18.3-1.fc26.s390x
net-tools-2.0-0.43.20160912git.fc26.s390x
python2-setuptools-37.0.0-1.fc26.noarch
python2-dnf-2.7.5-2.fc26.noarch
pcre2-10.23-11.fc26.s390x
groff-base-1.22.3-10.fc26.s390x
python2-devel-2.7.14-4.fc26.s390x
python2-GitPython-2.1.7-2.fc26.noarch
boost-iostreams-1.63.0-10.fc26.s390x
gpg-pubkey-efe550f5-5220ba41
gpg-pubkey-81b46521-55b3ca9a
filesystem-3.2-40.fc26.s390x
basesystem-11-3.fc26.noarch
js-jquery-3.2.1-1.fc26.noarch
pcre-8.41-3.fc26.s390x
elfutils-libelf-0.169-1.fc26.s390x
libidn-1.33-2.fc26.s390x
libogg-1.3.2-6.fc26.s390x
slang-2.3.1a-2.fc26.s390x
apr-1.6.3-1.fc26.s390x
libxkbcommon-0.7.1-3.fc26.s390x
perl-IO-1.36-395.fc26.s390x
libvorbis-1.3.5-2.fc26.s390x
less-487-3.fc26.s390x
lttng-ust-2.9.0-2.fc26.s390x
OpenEXR-libs-2.2.0-6.fc26.s390x
ipset-libs-6.29-3.fc26.s390x
perl-XML-XPath-1.42-1.fc26.noarch
lua-filesystem-1.6.3-3.fc24.s390x
sqlite-3.20.1-1.fc26.s390x
gstreamer1-1.12.3-1.fc26.s390x
libpwquality-1.3.0-8.fc26.s390x
gettext-libs-0.19.8.1-9.fc26.s390x
python3-chardet-2.3.0-3.fc26.noarch
python3-slip-dbus-0.6.4-6.fc26.noarch
python-chardet-2.3.0-3.fc26.noarch
python2-pyasn1-0.2.3-1.fc26.noarch
python-slip-dbus-0.6.4-6.fc26.noarch
libarchive-3.2.2-4.fc26.s390x
libbabeltrace-1.5.2-2.fc26.s390x
cdparanoia-libs-10.2-22.fc26.s390x
krb5-workstation-1.15.2-4.fc26.s390x
python3-requests-kerberos-0.10.0-4.fc26.noarch
gpgme-1.8.0-12.fc26.s390x
python2-gpg-1.8.0-12.fc26.s390x
shadow-utils-4.3.1-3.fc26.s390x
cryptsetup-libs-1.7.5-1.fc26.s390x
kpartx-0.4.9-88.fc26.s390x
net-snmp-agent-libs-5.7.3-17.fc26.s390x
libXi-1.7.9-2.fc26.s390x
texlive-tetex-svn41059-33.fc26.2.noarch
texlive-tools-svn40934-33.fc26.2.noarch
texlive-bibtex-bin-svn40473-33.20160520.fc26.2.s390x
texlive-mfware-bin-svn40473-33.20160520.fc26.2.s390x
texlive-underscore-svn18261.0-33.fc26.2.noarch
texlive-avantgar-svn31835.0-33.fc26.2.noarch
texlive-anysize-svn15878.0-33.fc26.2.noarch
texlive-lineno-svn21442.4.41-33.fc26.2.noarch
texlive-mathpazo-svn15878.1.003-33.fc26.2.noarch
texlive-soul-svn15878.2.4-33.fc26.2.noarch
texlive-luatexbase-svn38550-33.fc26.2.noarch
texlive-listings-svn37534.1.6-33.fc26.2.noarch
texlive-pstricks-svn41321-33.fc26.2.noarch
texlive-metalogo-svn18611.0.12-33.fc26.2.noarch
texlive-dvipdfmx-svn41149-33.fc26.2.noarch
kbd-legacy-2.0.4-2.fc26.noarch
nspr-devel-4.17.0-1.fc26.s390x
ghostscript-x11-9.20-10.fc26.s390x
libXrender-devel-0.9.10-2.fc26.s390x
libxkbcommon-devel-0.7.1-3.fc26.s390x
mesa-libGL-devel-17.2.4-2.fc26.s390x
sqlite-devel-3.20.1-1.fc26.s390x
usbredir-devel-0.7.1-3.fc26.s390x
libcap-devel-2.25-5.fc26.s390x
brlapi-devel-0.6.6-5.fc26.s390x
fedora-upgrade-27.1-1.fc26.noarch
python3-pygpgme-0.3-22.fc26.s390x
pinentry-0.9.7-3.fc26.s390x
perl-Test-Harness-3.39-1.fc26.noarch
qemu-sanity-check-nodeps-1.1.5-6.fc26.s390x
libldb-1.1.29-5.fc26.s390x
python-libxml2-2.9.4-2.fc26.s390x
nss-util-devel-3.34.0-1.0.fc26.s390x
vim-filesystem-8.0.1360-1.fc26.s390x
webkitgtk4-plugin-process-gtk2-2.18.3-1.fc26.s390x
python2-2.7.14-4.fc26.s390x
libwayland-cursor-1.13.0-3.fc26.s390x
mariadb-config-10.1.29-1.fc26.s390x
gdb-headless-8.0.1-33.fc26.s390x
pulseaudio-libs-devel-11.1-7.fc26.s390x
curl-7.53.1-13.fc26.s390x
json-c-0.12.1-5.fc26.s390x
gpg-pubkey-34ec9cba-54e38751
gpg-pubkey-030d5aed-55b577f0
setup-2.10.5-2.fc26.noarch
lato-fonts-2.015-3.fc26.noarch
web-assets-filesystem-5-5.fc26.noarch
libsepol-2.6-2.fc26.s390x
libcap-2.25-5.fc26.s390x
tcp_wrappers-libs-7.6-85.fc26.s390x
libnl3-3.3.0-1.fc26.s390x
pixman-0.34.0-3.fc26.s390x
lzo-2.08-9.fc26.s390x
perl-5.24.3-395.fc26.s390x
libnl3-cli-3.3.0-1.fc26.s390x
gpm-libs-1.20.7-10.fc26.s390x
libgo-7.2.1-2.fc26.s390x
iso-codes-3.74-2.fc26.noarch
ipset-6.29-3.fc26.s390x
lua-term-0.07-1.fc25.s390x
libdb-utils-5.3.28-24.fc26.s390x
system-python-libs-3.6.3-2.fc26.s390x
dbus-glib-0.108-2.fc26.s390x
pam-1.3.0-2.fc26.s390x
avahi-glib-0.6.32-7.fc26.s390x
python2-dateutil-2.6.0-3.fc26.noarch
python3-asn1crypto-0.23.0-1.fc26.noarch
python3-slip-0.6.4-6.fc26.noarch
python-backports-ssl_match_hostname-3.5.0.1-4.fc26.noarch
python2-pyOpenSSL-16.2.0-6.fc26.noarch
python-slip-0.6.4-6.fc26.noarch
nss-pem-1.0.3-3.fc26.s390x
fipscheck-1.5.0-1.fc26.s390x
elfutils-0.169-1.fc26.s390x
cyrus-sasl-lib-2.1.26-32.fc26.s390x
libkadm5-1.15.2-4.fc26.s390x
python3-kerberos-1.2.5-3.fc26.s390x
rpmconf-1.0.19-1.fc26.noarch
libsemanage-2.6-4.fc26.s390x
device-mapper-libs-1.02.137-6.fc26.s390x
yum-3.4.3-512.fc26.noarch
device-mapper-multipath-0.4.9-88.fc26.s390x
net-snmp-5.7.3-17.fc26.s390x
libXtst-1.2.3-2.fc26.s390x
libXxf86vm-1.1.4-4.fc26.s390x
texlive-amsmath-svn41561-33.fc26.2.noarch
texlive-xkeyval-svn35741.2.7a-33.fc26.2.noarch
texlive-bibtex-svn40768-33.fc26.2.noarch
texlive-mfware-svn40768-33.fc26.2.noarch
texlive-wasy-svn35831.0-33.fc26.2.noarch
texlive-bookman-svn31835.0-33.fc26.2.noarch
texlive-babel-english-svn30264.3.3p-33.fc26.2.noarch
texlive-fix2col-svn38770-33.fc26.2.noarch
texlive-mdwtools-svn15878.1.05.4-33.fc26.2.noarch
texlive-tex-gyre-math-svn41264-33.fc26.2.noarch
texlive-luaotfload-svn40902-33.fc26.2.noarch
texlive-showexpl-svn32737.v0.3l-33.fc26.2.noarch
texlive-pstricks-add-svn40744-33.fc26.2.noarch
texlive-l3experimental-svn41163-33.fc26.2.noarch
texlive-xetex-bin-svn41091-33.20160520.fc26.2.s390x
kbd-misc-2.0.4-2.fc26.noarch
libpng-devel-1.6.28-2.fc26.s390x
ghostscript-core-9.20-10.fc26.s390x
libXfixes-devel-5.0.3-2.fc26.s390x
libverto-devel-0.2.6-7.fc26.s390x
mesa-libEGL-devel-17.2.4-2.fc26.s390x
popt-devel-1.16-12.fc26.s390x
readline-devel-7.0-5.fc26.s390x
cyrus-sasl-devel-2.1.26-32.fc26.s390x
sendmail-8.15.2-19.fc26.s390x
systemd-bootchart-231-3.fc26.s390x
perl-IO-Socket-SSL-2.049-1.fc26.noarch
python2-enchant-1.6.10-1.fc26.noarch
perl-generators-1.10-2.fc26.noarch
createrepo-0.10.3-11.fc26.noarch
webkitgtk4-jsc-2.18.3-1.fc26.s390x
vim-common-8.0.1360-1.fc26.s390x
nss-tools-3.34.0-1.0.fc26.s390x
glusterfs-api-3.10.8-1.fc26.s390x
pulseaudio-libs-glib2-11.1-7.fc26.s390x
mariadb-common-10.1.29-1.fc26.s390x
dhcp-libs-4.3.5-10.fc26.s390x
pcre2-devel-10.23-11.fc26.s390x
libtiff-4.0.9-1.fc26.s390x
kernel-headers-4.14.8-200.fc26.s390x
fontpackages-filesystem-1.44-18.fc26.noarch
vte-profile-0.48.4-1.fc26.s390x
texlive-kpathsea-doc-svn41139-33.fc26.2.noarch
zlib-1.2.11-2.fc26.s390x
readline-7.0-5.fc26.s390x
libattr-2.4.47-18.fc26.s390x
libgomp-7.2.1-2.fc26.s390x
libglvnd-1.0.0-1.fc26.s390x
lz4-libs-1.8.0-1.fc26.s390x
libcrypt-nss-2.25-12.fc26.s390x
jansson-2.10-2.fc26.s390x
perl-File-Path-2.12-367.fc26.noarch
perl-Unicode-EastAsianWidth-1.33-9.fc26.noarch
hunspell-1.5.4-2.fc26.s390x
libasyncns-0.8-11.fc26.s390x
libnetfilter_conntrack-1.0.6-2.fc26.s390x
perl-Storable-2.56-368.fc26.s390x
autoconf-2.69-24.fc26.noarch
device-mapper-persistent-data-0.6.3-5.fc26.s390x
quota-4.03-9.fc26.s390x
crypto-policies-20170606-1.git7c32281.fc26.noarch
glib2-2.52.3-2.fc26.s390x
python2-idna-2.5-1.fc26.noarch
python2-libcomps-0.1.8-3.fc26.s390x
gsettings-desktop-schemas-3.24.1-1.fc26.s390x
javapackages-tools-4.7.0-17.fc26.noarch
libselinux-python3-2.6-7.fc26.s390x
python-backports-1.0-9.fc26.s390x
python2-cryptography-2.0.2-2.fc26.s390x
libselinux-python-2.6-7.fc26.s390x
Lmod-7.5.3-1.fc26.s390x
fipscheck-lib-1.5.0-1.fc26.s390x
elfutils-libs-0.169-1.fc26.s390x
krb5-libs-1.15.2-4.fc26.s390x
libuser-0.62-6.fc26.s390x
python2-requests-kerberos-0.10.0-4.fc26.noarch
npth-1.5-1.fc26.s390x
packagedb-cli-2.14.1-2.fc26.noarch
ustr-1.0.4-22.fc26.s390x
device-mapper-1.02.137-6.fc26.s390x
polkit-pkla-compat-0.1-8.fc26.s390x
fakeroot-1.22-1.fc26.s390x
libXmu-1.1.2-5.fc26.s390x
cairo-gobject-1.14.10-1.fc26.s390x
texlive-booktabs-svn40846-33.fc26.2.noarch
texlive-dvips-bin-svn40987-33.20160520.fc26.2.s390x
texlive-float-svn15878.1.3d-33.fc26.2.noarch
texlive-tex-svn40793-33.fc26.2.noarch
texlive-fancyref-svn15878.0.9c-33.fc26.2.noarch
texlive-manfnt-font-svn35799.0-33.fc26.2.noarch
texlive-cmap-svn41168-33.fc26.2.noarch
texlive-hyph-utf8-svn41189-33.fc26.2.noarch
texlive-paralist-svn39247-33.fc26.2.noarch
texlive-trimspaces-svn15878.1.1-33.fc26.2.noarch
texlive-tipa-svn29349.1.3-33.fc26.2.noarch
texlive-l3packages-svn41246-33.fc26.2.noarch
texlive-pst-pdf-svn31660.1.1v-33.fc26.2.noarch
texlive-tex-gyre-svn18651.2.004-33.fc26.2.noarch
texlive-beamer-svn36461.3.36-33.fc26.2.noarch
gd-2.2.5-1.fc26.s390x
elfutils-libelf-devel-0.169-1.fc26.s390x
gc-devel-7.6.0-2.fc26.s390x
libXft-devel-2.3.2-5.fc26.s390x
krb5-devel-1.15.2-4.fc26.s390x
rpm-devel-4.13.0.2-1.fc26.s390x
pcre-static-8.41-3.fc26.s390x
bluez-libs-devel-5.46-6.fc26.s390x
systemtap-3.2-2.fc26.s390x
trousers-0.3.13-7.fc26.s390x
iproute-tc-4.11.0-1.fc26.s390x
python2-sphinx-1.5.5-1.fc26.noarch
libgnome-keyring-3.12.0-8.fc26.s390x
perl-File-ShareDir-1.102-8.fc26.noarch
python2-paramiko-2.2.1-1.fc26.noarch
python2-openidc-client-0.4.0-1.20171113git54dee6e.fc26.noarch
openssh-server-7.5p1-4.fc26.s390x
pulseaudio-libs-11.1-7.fc26.s390x
python2-bodhi-2.12.2-3.fc26.noarch
lua-libs-5.3.4-7.fc26.s390x
dhcp-common-4.3.5-10.fc26.noarch
python3-pip-9.0.1-11.fc26.noarch
python3-sssdconfig-1.16.0-4.fc26.noarch
gpg-pubkey-95a43f54-5284415a
gpg-pubkey-fdb19c98-56fd6333
gpg-pubkey-64dab85d-57d33e22
tzdata-2017c-1.fc26.noarch
firewalld-filesystem-0.4.4.5-1.fc26.noarch
xkeyboard-config-2.21-3.fc26.noarch
texlive-texlive-common-doc-svn40682-33.fc26.2.noarch
ncurses-base-6.0-8.20170212.fc26.noarch
libselinux-2.6-7.fc26.s390x
bzip2-libs-1.0.6-22.fc26.s390x
libdb-5.3.28-24.fc26.s390x
mpfr-3.1.5-3.fc26.s390x
file-libs-5.30-11.fc26.s390x
libunistring-0.9.7-1.fc26.s390x
libxslt-1.1.29-1.fc26.s390x
libtasn1-4.12-1.fc26.s390x
gdbm-1.13-1.fc26.s390x
libepoxy-1.4.3-1.fc26.s390x
libpsl-0.18.0-1.fc26.s390x
perl-Carp-1.40-366.fc26.noarch
e2fsprogs-libs-1.43.4-2.fc26.s390x
libmnl-1.0.4-2.fc26.s390x
openjpeg2-2.2.0-3.fc26.s390x
perl-PathTools-3.63-367.fc26.s390x
perl-File-Temp-0.230.400-2.fc26.noarch
perl-XML-Parser-2.44-6.fc26.s390x
libss-1.43.4-2.fc26.s390x
ilmbase-2.2.0-8.fc26.s390x
fuse-libs-2.9.7-2.fc26.s390x
libdaemon-0.14-11.fc26.s390x
libbasicobjects-0.1.1-34.fc26.s390x
iptables-1.6.1-2.fc26.s390x
perl-TermReadKey-2.37-2.fc26.s390x
perl-Term-ANSIColor-4.06-2.fc26.noarch
perl-libintl-perl-1.26-2.fc26.s390x
usbredir-0.7.1-3.fc26.s390x
fftw-libs-double-3.3.5-4.fc26.s390x
rsync-3.1.2-5.fc26.s390x
libiscsi-1.15.0-3.fc26.s390x
ttmkfdir-3.0.9-49.fc26.s390x
texlive-base-2016-33.20160520.fc26.1.noarch
python2-six-1.10.0-9.fc26.noarch
atk-2.24.0-1.fc26.s390x
python2-kitchen-1.2.4-6.fc26.noarch
guile-2.0.14-1.fc26.s390x
desktop-file-utils-0.23-3.fc26.s390x
pyxattr-0.5.3-10.fc26.s390x
shared-mime-info-1.8-2.fc26.s390x
libyaml-0.1.7-2.fc26.s390x
python3-PyYAML-3.12-3.fc26.s390x
openssh-7.5p1-4.fc26.s390x
kernel-core-4.13.16-202.fc26.s390x
perl-Git-2.13.6-2.fc26.noarch
python3-dnf-plugins-extras-common-2.0.4-1.fc26.noarch
openssl-1.1.0g-1.fc26.s390x
gawk-4.1.4-6.fc26.s390x
gnutls-3.5.16-4.fc26.s390x
openldap-2.4.45-2.fc26.s390x
bind-license-9.11.1-4.P3.fc26.noarch
python2-gluster-3.10.8-1.fc26.s390x
selinux-policy-3.13.1-260.17.fc26.noarch
linux-firmware-20171215-81.git2451bb22.fc26.noarch
libpkgconf-1.3.12-1.fc26.s390x
NetworkManager-libnm-1.8.2-4.fc26.s390x
gnutls-devel-3.5.16-4.fc26.s390x
mariadb-libs-10.1.29-1.fc26.s390x
python2-urllib3-1.20-2.fc26.noarch
sssd-nfs-idmap-1.16.0-4.fc26.s390x
libsss_sudo-1.16.0-4.fc26.s390x
libgudev-232-1.fc26.s390x
python3-libs-3.6.3-2.fc26.s390x
python3-javapackages-4.7.0-17.fc26.noarch
python3-ply-3.9-3.fc26.noarch
python3-systemd-234-1.fc26.s390x
python3-requests-2.13.0-1.fc26.noarch
blktrace-1.1.0-4.fc26.s390x
python2-asn1crypto-0.23.0-1.fc26.noarch
python2-cffi-1.9.1-2.fc26.s390x
python2-sphinx_rtd_theme-0.2.4-1.fc26.noarch
lua-json-1.3.2-7.fc26.noarch
libcephfs1-10.2.7-2.fc26.s390x
glib-networking-2.50.0-2.fc26.s390x
elfutils-default-yama-scope-0.169-1.fc26.noarch
GeoIP-GeoLite-data-2017.10-1.fc26.noarch
libedit-3.1-17.20160618cvs.fc26.s390x
libverto-libev-0.2.6-7.fc26.s390x
libserf-1.3.9-3.fc26.s390x
createrepo_c-0.10.0-9.fc26.s390x
python2-kerberos-1.2.5-3.fc26.s390x
libsrtp-1.5.4-4.fc26.s390x
lzo-minilzo-2.08-9.fc26.s390x
librepo-1.8.0-1.fc26.s390x
koji-1.14.0-1.fc26.noarch
sg3_utils-1.42-1.fc26.s390x
libobjc-7.2.1-2.fc26.s390x
policycoreutils-2.6-6.fc26.s390x
libdrm-2.4.88-1.fc26.s390x
kernel-core-4.13.13-200.fc26.s390x
systemtap-client-3.2-2.fc26.s390x
lvm2-2.02.168-6.fc26.s390x
device-mapper-multipath-libs-0.4.9-88.fc26.s390x
libfdt-1.4.5-1.fc26.s390x
s390utils-cmsfs-1.36.1-3.fc26.s390x
libXdamage-1.1.4-9.fc26.s390x
libXaw-1.0.13-5.fc26.s390x
brltty-5.5-5.fc26.s390x
librsvg2-2.40.18-1.fc26.s390x
texlive-tetex-bin-svn36770.0-33.20160520.fc26.2.noarch
texlive-etex-pkg-svn39355-33.fc26.2.noarch
texlive-graphics-svn41015-33.fc26.2.noarch
texlive-dvips-svn41149-33.fc26.2.noarch
texlive-zapfding-svn31835.0-33.fc26.2.noarch
texlive-footmisc-svn23330.5.5b-33.fc26.2.noarch
texlive-makeindex-svn40768-33.fc26.2.noarch
texlive-pst-ovl-svn40873-33.fc26.2.noarch
texlive-texlive-scripts-svn41433-33.fc26.2.noarch
texlive-ltabptch-svn17533.1.74d-33.fc26.2.noarch
texlive-euro-svn22191.1.1-33.fc26.2.noarch
texlive-mflogo-font-svn36898.1.002-33.fc26.2.noarch
texlive-zapfchan-svn31835.0-33.fc26.2.noarch
texlive-cmextra-svn32831.0-33.fc26.2.noarch
texlive-finstrut-svn21719.0.5-33.fc26.2.noarch
texlive-hyphen-base-svn41138-33.fc26.2.noarch
texlive-marginnote-svn41382-33.fc26.2.noarch
texlive-parallel-svn15878.0-33.fc26.2.noarch
texlive-sepnum-svn20186.2.0-33.fc26.2.noarch
texlive-environ-svn33821.0.3-33.fc26.2.noarch
texlive-type1cm-svn21820.0-33.fc26.2.noarch
texlive-xunicode-svn30466.0.981-33.fc26.2.noarch
texlive-attachfile-svn38830-33.fc26.2.noarch
texlive-fontspec-svn41262-33.fc26.2.noarch
texlive-fancyvrb-svn18492.2.8-33.fc26.2.noarch
texlive-pst-pdf-bin-svn7838.0-33.20160520.fc26.2.noarch
texlive-xcolor-svn41044-33.fc26.2.noarch
texlive-pdfpages-svn40638-33.fc26.2.noarch
texlive-sansmathaccent-svn30187.0-33.fc26.2.noarch
texlive-ucs-svn35853.2.2-33.fc26.2.noarch
texlive-dvipdfmx-bin-svn40273-33.20160520.fc26.2.s390x
libotf-0.9.13-8.fc26.s390x
go-srpm-macros-2-8.fc26.noarch
pcre-devel-8.41-3.fc26.s390x
mesa-libwayland-egl-devel-17.2.4-2.fc26.s390x
ghostscript-9.20-10.fc26.s390x
libcephfs_jni-devel-10.2.7-2.fc26.s390x
libXdamage-devel-1.1.4-9.fc26.s390x
freetype-devel-2.7.1-9.fc26.s390x
ncurses-devel-6.0-8.20170212.fc26.s390x
fontconfig-devel-2.12.6-4.fc26.s390x
cairo-devel-1.14.10-1.fc26.s390x
libselinux-devel-2.6-7.fc26.s390x
guile-devel-2.0.14-1.fc26.s390x
libcap-ng-devel-0.7.8-3.fc26.s390x
bash-completion-2.6-1.fc26.noarch
libXevie-1.0.3-12.fc26.s390x
kernel-4.13.13-200.fc26.s390x
audit-2.8.1-1.fc26.s390x
gcc-objc-7.2.1-2.fc26.s390x
gcc-go-7.2.1-2.fc26.s390x
python-firewall-0.4.4.5-1.fc26.noarch
python3-html5lib-0.999-13.fc26.noarch
python2-simplejson-3.10.0-3.fc26.s390x
flex-2.6.1-3.fc26.s390x
telnet-0.17-69.fc26.s390x
gpg-pubkey-8e1431d5-53bcbac7
emacs-filesystem-25.3-3.fc26.noarch
fontawesome-fonts-4.7.0-2.fc26.noarch
fontawesome-fonts-web-4.7.0-2.fc26.noarch
tzdata-java-2017c-1.fc26.noarch
rpmconf-base-1.0.19-1.fc26.noarch
glibc-2.25-12.fc26.s390x
info-6.3-3.fc26.s390x
sqlite-libs-3.20.1-1.fc26.s390x
texlive-lib-2016-33.20160520.fc26.1.s390x
sed-4.4-1.fc26.s390x
libicu-57.1-7.fc26.s390x
libcap-ng-0.7.8-3.fc26.s390x
nettle-3.3-2.fc26.s390x
libidn2-2.0.4-1.fc26.s390x
lcms2-2.8-3.fc26.s390x
dbus-libs-1.11.18-1.fc26.s390x
perl-Exporter-5.72-367.fc26.noarch
unzip-6.0-34.fc26.s390x
iproute-4.11.0-1.fc26.s390x
zip-3.0-18.fc26.s390x
perl-constant-1.33-368.fc26.noarch
perl-MIME-Base64-3.15-366.fc26.s390x
lua-posix-33.3.1-4.fc26.s390x
bzip2-1.0.6-22.fc26.s390x
libstdc++-devel-7.2.1-2.fc26.s390x
hyphen-2.8.8-6.fc26.s390x
libdvdread-5.0.3-4.fc26.s390x
libcollection-0.7.0-34.fc26.s390x
libdvdnav-5.0.3-5.fc26.s390x
perl-version-0.99.18-1.fc26.s390x
perl-Encode-2.88-6.fc26.s390x
automake-1.15-9.fc26.noarch
plymouth-core-libs-0.9.3-0.7.20160620git0e65b86c.fc26.s390x
hesiod-3.2.1-7.fc26.s390x
jasper-libs-2.0.14-1.fc26.s390x
mozjs17-17.0.0-18.fc26.s390x
fontconfig-2.12.6-4.fc26.s390x
harfbuzz-1.4.4-1.fc26.s390x
alsa-lib-1.1.4.1-1.fc26.s390x
make-4.2.1-2.fc26.s390x
gobject-introspection-1.52.1-1.fc26.s390x
hicolor-icon-theme-0.15-5.fc26.noarch
gdk-pixbuf2-2.36.9-1.fc26.s390x
libgusb-0.2.11-1.fc26.s390x
libtalloc-2.1.10-2.fc26.s390x
libdhash-0.5.0-34.fc26.s390x
python2-bcrypt-3.1.4-2.fc26.s390x
PyYAML-3.12-3.fc26.s390x
nss-softokn-freebl-3.34.0-1.0.fc26.s390x
kernel-modules-4.13.16-202.fc26.s390x
git-2.13.6-2.fc26.s390x
gnupg2-smime-2.2.3-1.fc26.s390x
openssl-devel-1.1.0g-1.fc26.s390x
python2-dnf-plugins-extras-common-2.0.4-1.fc26.noarch
copy-jdk-configs-3.3-2.fc26.noarch
glusterfs-client-xlators-3.10.8-1.fc26.s390x
libcurl-7.53.1-13.fc26.s390x
bind-libs-lite-9.11.1-4.P3.fc26.s390x
glusterfs-extra-xlators-3.10.8-1.fc26.s390x
python3-setuptools-37.0.0-1.fc26.noarch
kernel-core-4.14.8-200.fc26.s390x
pkgconf-1.3.12-1.fc26.s390x
NetworkManager-1.8.2-4.fc26.s390x
libjpeg-turbo-devel-1.5.3-1.fc26.s390x
lua-5.3.4-7.fc26.s390x
boost-thread-1.63.0-10.fc26.s390x
wget-1.19.2-2.fc26.s390x
libwebp-0.6.1-1.fc26.s390x
kernel-devel-4.14.8-200.fc26.s390x
python3-lxml-4.1.1-1.fc26.s390x
python3-ordered-set-2.0.0-6.fc26.noarch
python3-rpmconf-1.0.19-1.fc26.noarch
python-offtrac-0.1.0-9.fc26.noarch
python2-pycparser-2.14-10.fc26.noarch
python2-sphinx-theme-alabaster-0.7.9-3.fc26.noarch
python2-pysocks-1.6.7-1.fc26.noarch
lua-lpeg-1.0.1-2.fc26.s390x
poppler-0.52.0-10.fc26.s390x
libproxy-0.4.15-2.fc26.s390x
crontabs-1.11-14.20150630git.fc26.noarch
java-1.8.0-openjdk-headless-1.8.0.151-1.b12.fc26.s390x
libev-4.24-2.fc26.s390x
libsigsegv-2.11-1.fc26.s390x
fedora-cert-0.6.0.1-2.fc26.noarch
drpm-0.3.0-6.fc26.s390x
createrepo_c-libs-0.10.0-9.fc26.s390x
python2-cccolutils-1.5-3.fc26.s390x
m17n-lib-1.7.0-6.fc26.s390x
lsscsi-0.28-4.fc26.s390x
python2-koji-1.14.0-1.fc26.noarch
python3-koji-1.14.0-1.fc26.noarch
python3-gpg-1.8.0-12.fc26.s390x
sg3_utils-libs-1.42-1.fc26.s390x
SDL2-2.0.7-2.fc26.s390x
util-linux-2.30.2-1.fc26.s390x
rpcbind-0.2.4-8.rc2.fc26.s390x
s390utils-mon_statd-1.36.1-3.fc26.s390x
GConf2-3.2.6-17.fc26.s390x
systemd-container-233-7.fc26.s390x
usermode-1.111-9.fc26.s390x
pcre-utf32-8.41-3.fc26.s390x
libXt-1.1.5-4.fc26.s390x
libXpm-3.5.12-2.fc26.s390x
at-spi2-core-2.24.1-1.fc26.s390x
cairo-1.14.10-1.fc26.s390x
texlive-kpathsea-bin-svn40473-33.20160520.fc26.2.s390x
texlive-ifluatex-svn41346-33.fc26.2.noarch
texlive-babel-svn40706-33.fc26.2.noarch
texlive-colortbl-svn29803.v1.0a-33.fc26.2.noarch
texlive-marvosym-svn29349.2.2a-33.fc26.2.noarch
texlive-euler-svn17261.2.5-33.fc26.2.noarch
texlive-latexconfig-svn40274-33.fc26.2.noarch
texlive-plain-svn40274-33.fc26.2.noarch
texlive-texconfig-bin-svn29741.0-33.20160520.fc26.2.noarch
giflib-4.1.6-16.fc26.s390x
texlive-microtype-svn41127-33.fc26.2.noarch
texlive-eurosym-svn17265.1.4_subrfix-33.fc26.2.noarch
texlive-symbol-svn31835.0-33.fc26.2.noarch
texlive-chngcntr-svn17157.1.0a-33.fc26.2.noarch
texlive-euenc-svn19795.0.1h-33.fc26.2.noarch
texlive-luatex-svn40963-33.fc26.2.noarch
texlive-knuth-local-svn38627-33.fc26.2.noarch
texlive-mparhack-svn15878.1.4-33.fc26.2.noarch
texlive-rcs-svn15878.0-33.fc26.2.noarch
texlive-texlive-msg-translations-svn41431-33.fc26.2.noarch
texlive-updmap-map-svn41159-33.fc26.2.noarch
texlive-geometry-svn19716.5.6-33.fc26.2.noarch
texlive-memoir-svn41203-33.fc26.2.noarch
texlive-l3kernel-svn41246-33.fc26.2.noarch
texlive-pst-eps-svn15878.1.0-33.fc26.2.noarch
texlive-pst-text-svn15878.1.00-33.fc26.2.noarch
texlive-amscls-svn36804.0-33.fc26.2.noarch
texlive-pst-slpe-svn24391.1.31-33.fc26.2.noarch
texlive-extsizes-svn17263.1.4a-33.fc26.2.noarch
texlive-xetex-def-svn40327-33.fc26.2.noarch
texlive-collection-latex-svn41011-33.20160520.fc26.2.noarch
gstreamer1-plugins-base-1.12.3-1.fc26.s390x
fpc-srpm-macros-1.1-2.fc26.noarch
xorg-x11-proto-devel-7.7-22.fc26.noarch
urw-fonts-2.4-23.fc26.noarch
atk-devel-2.24.0-1.fc26.s390x
ImageMagick-libs-6.9.9.22-1.fc26.s390x
libxcb-devel-1.12-3.fc26.s390x
libXrandr-devel-1.5.1-2.fc26.s390x
libcom_err-devel-1.43.4-2.fc26.s390x
dbus-devel-1.11.18-1.fc26.s390x
libepoxy-devel-1.4.3-1.fc26.s390x
libicu-devel-57.1-7.fc26.s390x
p11-kit-devel-0.23.9-2.fc26.s390x
rpm-build-4.13.0.2-1.fc26.s390x
libssh2-devel-1.8.0-5.fc26.s390x
graphviz-2.40.1-4.fc26.s390x
zlib-static-1.2.11-2.fc26.s390x
mesa-libgbm-devel-17.2.4-2.fc26.s390x
dracut-config-rescue-046-3.1.fc26.s390x
screen-4.6.2-1.fc26.s390x
python-osbs-client-0.39.1-1.fc26.noarch
gcc-gdb-plugin-7.2.1-2.fc26.s390x
pyparsing-2.1.10-3.fc26.noarch
python3-pyasn1-0.2.3-1.fc26.noarch
python2-html5lib-0.999-13.fc26.noarch
teamd-1.27-1.fc26.s390x
hardlink-1.3-1.fc26.s390x
chrpath-0.16-4.fc26.s390x
libgcc-7.2.1-2.fc26.s390x
python-rpm-macros-3-20.fc26.noarch
texlive-pdftex-doc-svn41149-33.fc26.2.noarch
glibc-common-2.25-12.fc26.s390x
libstdc++-7.2.1-2.fc26.s390x
nspr-4.17.0-1.fc26.s390x
grep-3.1-1.fc26.s390x
libgcrypt-1.7.9-1.fc26.s390x
libacl-2.2.52-15.fc26.s390x
cpio-2.12-4.fc26.s390x
libatomic_ops-7.4.4-2.fc26.s390x
p11-kit-0.23.9-2.fc26.s390x
gc-7.6.0-2.fc26.s390x
psmisc-22.21-9.fc26.s390x
systemd-libs-233-7.fc26.s390x
xz-5.2.3-2.fc26.s390x
perl-libs-5.24.3-395.fc26.s390x
kmod-libs-24-1.fc26.s390x
libpcap-1.8.1-3.fc26.s390x
perl-macros-5.24.3-395.fc26.s390x
perl-parent-0.236-2.fc26.noarch
perl-Text-Unidecode-1.30-2.fc26.noarch
newt-0.52.20-1.fc26.s390x
libcomps-0.1.8-3.fc26.s390x
libfontenc-1.1.3-4.fc26.s390x
ipcalc-0.2.0-1.fc26.s390x
libnfnetlink-1.0.1-9.fc26.s390x
libref_array-0.1.5-34.fc26.s390x
perl-Term-Cap-1.17-366.fc26.noarch
perl-Digest-1.17-367.fc26.noarch
perl-SelfLoader-1.23-395.fc26.noarch
perl-Pod-Simple-3.35-2.fc26.noarch
perl-URI-1.71-6.fc26.noarch
cpp-7.2.1-2.fc26.s390x
attr-2.4.47-18.fc26.s390x
gmp-c++-6.1.2-4.fc26.s390x
xapian-core-libs-1.4.4-1.fc26.s390x
system-python-3.6.3-2.fc26.s390x
harfbuzz-icu-1.4.4-1.fc26.s390x
libtevent-0.9.34-1.fc26.s390x
http-parser-2.7.1-5.fc26.s390x
libsodium-1.0.14-1.fc26.s390x
python-gssapi-1.2.0-5.fc26.s390x
nss-softokn-3.34.0-1.0.fc26.s390x
gnupg2-2.2.3-1.fc26.s390x
nss-devel-3.34.0-1.0.fc26.s390x
vim-minimal-8.0.1360-1.fc26.s390x
perl-libnet-3.11-1.fc26.noarch
kernel-devel-4.13.16-202.fc26.s390x
python2-libs-2.7.14-4.fc26.s390x
libwayland-client-1.13.0-3.fc26.s390x
python3-dnf-2.7.5-2.fc26.noarch
glusterfs-fuse-3.10.8-1.fc26.s390x
pcre2-utf32-10.23-11.fc26.s390x
kernel-modules-4.14.8-200.fc26.s390x
pkgconf-pkg-config-1.3.12-1.fc26.s390x
NetworkManager-ppp-1.8.2-4.fc26.s390x
wayland-devel-1.13.0-3.fc26.s390x
kernel-4.14.8-200.fc26.s390x
boost-random-1.63.0-10.fc26.s390x
libmicrohttpd-0.9.58-1.fc26.s390x
mailx-12.5-24.fc26.s390x
NetworkManager-glib-1.8.2-4.fc26.s390x
libcroco-0.6.12-1.fc26.s390x
libssh2-1.8.0-5.fc26.s390x
json-glib-1.2.6-1.fc26.s390x
libevent-2.0.22-3.fc26.s390x
gdk-pixbuf2-modules-2.36.9-1.fc26.s390x
colord-libs-1.3.5-1.fc26.s390x
python3-magic-5.30-11.fc26.noarch
python3-gobject-base-3.24.1-1.fc26.s390x
python3-pyroute2-0.4.13-1.fc26.noarch
python3-pysocks-1.6.7-1.fc26.noarch
python2-click-6.7-3.fc26.noarch
python-munch-2.1.0-2.fc26.noarch
python2-ply-3.9-3.fc26.noarch
python2-snowballstemmer-1.2.1-3.fc26.noarch
python-magic-5.30-11.fc26.noarch
python-beautifulsoup4-4.6.0-1.fc26.noarch
python2-gitdb-2.0.3-1.fc26.noarch
librados-devel-10.2.7-2.fc26.s390x
libcacard-2.5.3-1.fc26.s390x
libmodman-2.0.1-13.fc26.s390x
zziplib-0.13.62-8.fc26.s390x
lksctp-tools-1.0.16-6.fc26.s390x
procmail-3.22-44.fc26.s390x
libthai-0.1.25-2.fc26.s390x
libpipeline-1.4.1-3.fc26.s390x
python2-pycurl-7.43.0-8.fc26.s390x
deltarpm-3.6-19.fc26.s390x
subversion-libs-1.9.7-1.fc26.s390x
python-krbV-1.0.90-13.fc26.s390x
m17n-db-1.7.0-8.fc26.noarch
linux-atm-libs-2.5.1-17.fc26.s390x
python2-rpm-4.13.0.2-1.fc26.s390x
python2-librepo-1.8.0-1.fc26.s390x
python2-dnf-plugins-core-2.1.5-1.fc26.noarch
qrencode-libs-3.4.4-1.fc26.s390x
s390utils-iucvterm-1.36.1-3.fc26.s390x
libsmartcols-2.30.2-1.fc26.s390x
dbus-1.11.18-1.fc26.s390x
systemd-udev-233-7.fc26.s390x
device-mapper-event-1.02.137-6.fc26.s390x
polkit-0.113-8.fc26.s390x
mock-1.4.7-2.fc26.noarch
libwmf-lite-0.2.8.4-53.fc26.s390x
libXcomposite-0.4.4-9.fc26.s390x
libXcursor-1.1.14-8.fc26.s390x
at-spi2-atk-2.24.1-1.fc26.s390x
pango-1.40.12-1.fc26.s390x
texlive-metafont-bin-svn40987-33.20160520.fc26.2.s390x
texlive-url-svn32528.3.4-33.fc26.2.noarch
texlive-fp-svn15878.0-33.fc26.2.noarch
texlive-latex-fonts-svn28888.0-33.fc26.2.noarch
texlive-mptopdf-bin-svn18674.0-33.20160520.fc26.2.noarch
texlive-fancybox-svn18304.1.4-33.fc26.2.noarch
texlive-lua-alt-getopt-svn29349.0.7.0-33.fc26.2.noarch
texlive-tex-bin-svn40987-33.20160520.fc26.2.s390x
texlive-texconfig-svn40768-33.fc26.2.noarch
texlive-wasy2-ps-svn35830.0-33.fc26.2.noarch
texlive-psfrag-svn15878.3.04-33.fc26.2.noarch
texlive-helvetic-svn31835.0-33.fc26.2.noarch
texlive-times-svn35058.0-33.fc26.2.noarch
texlive-cite-svn36428.5.5-33.fc26.2.noarch
texlive-fancyhdr-svn15878.3.1-33.fc26.2.noarch
texlive-luatex-bin-svn41091-33.20160520.fc26.2.s390x
texlive-lm-math-svn36915.1.959-33.fc26.2.noarch
texlive-ntgclass-svn15878.2.1a-33.fc26.2.noarch
texlive-sansmath-svn17997.1.1-33.fc26.2.noarch
texlive-textcase-svn15878.0-33.fc26.2.noarch
texlive-unicode-data-svn39808-33.fc26.2.noarch
texlive-breakurl-svn29901.1.40-33.fc26.2.noarch
texlive-latex-svn40218-33.fc26.2.noarch
texlive-lualatex-math-svn40621-33.fc26.2.noarch
texlive-pst-coil-svn37377.1.07-33.fc26.2.noarch
texlive-pst-plot-svn41242-33.fc26.2.noarch
texlive-unicode-math-svn38462-33.fc26.2.noarch
texlive-pst-blur-svn15878.2.0-33.fc26.2.noarch
texlive-cm-super-svn15878.0-33.fc26.2.noarch
texlive-wasysym-svn15878.2.0-33.fc26.2.noarch
texlive-collection-fontsrecommended-svn35830.0-33.20160520.fc26.2.noarch
libXv-1.0.11-2.fc26.s390x
ghc-srpm-macros-1.4.2-5.fc26.noarch
latex2html-2017.2-2.fc26.noarch
libXau-devel-1.0.8-7.fc26.s390x
libXcursor-devel-1.1.14-8.fc26.s390x
graphite2-devel-1.3.10-1.fc26.s390x
pixman-devel-0.34.0-3.fc26.s390x
wayland-protocols-devel-1.9-1.fc26.noarch
mesa-libGLES-devel-17.2.4-2.fc26.s390x
redhat-rpm-config-63-1.fc26.noarch
vte291-devel-0.48.4-1.fc26.s390x
ceph-devel-compat-10.2.7-2.fc26.s390x
lzo-devel-2.08-9.fc26.s390x
libiscsi-devel-1.15.0-3.fc26.s390x
libfdt-devel-1.4.5-1.fc26.s390x
dnsmasq-2.76-5.fc26.s390x
avahi-autoipd-0.6.32-7.fc26.s390x
rpm-plugin-systemd-inhibit-4.13.0.2-1.fc26.s390x
gcc-c++-7.2.1-2.fc26.s390x
python2-ndg_httpsclient-0.4.0-7.fc26.noarch
gettext-0.19.8.1-9.fc26.s390x
btrfs-progs-4.9.1-2.fc26.s390x
fedora-logos-26.0.1-1.fc26.s390x
dejagnu-1.6-2.fc26.noarch
libaio-devel-0.3.110-7.fc26.s390x
dos2unix-7.3.4-2.fc26.s390x
distribution-gpg-keys-1.15-1.fc26.noarch
python-sphinx-locale-1.5.5-1.fc26.noarch
python2-rpm-macros-3-20.fc26.noarch
libxml2-2.9.4-2.fc26.s390x
popt-1.16-12.fc26.s390x
tar-1.29-5.fc26.s390x
avahi-libs-0.6.32-7.fc26.s390x
m4-1.4.18-3.fc26.s390x
perl-Socket-2.024-2.fc26.s390x
perl-Time-Local-1.250-2.fc26.noarch
libmetalink-0.1.3-2.fc26.s390x
jbigkit-libs-2.1-6.fc26.s390x
netpbm-10.80.00-2.fc26.s390x
perl-Digest-MD5-2.55-3.fc26.s390x
perl-Getopt-Long-2.49.1-2.fc26.noarch
libglvnd-opengl-1.0.0-1.fc26.s390x
libattr-devel-2.4.47-18.fc26.s390x
teckit-2.5.1-16.fc26.s390x
python3-six-1.10.0-9.fc26.noarch
python3-libcomps-0.1.8-3.fc26.s390x
gtk-update-icon-cache-3.22.21-2.fc26.s390x
python3-3.6.3-2.fc26.s390x
python3-pyparsing-2.1.10-3.fc26.noarch
python2-markupsafe-0.23-13.fc26.s390x
python2-mock-2.0.0-4.fc26.noarch
python2-yubico-1.3.2-7.fc26.noarch
python2-smmap-2.0.3-1.fc26.noarch
librbd-devel-10.2.7-2.fc26.s390x
pigz-2.3.4-2.fc26.s390x
gcc-7.2.1-2.fc26.s390x
libnghttp2-1.21.1-1.fc26.s390x
cups-libs-2.2.2-7.fc26.s390x
libnfsidmap-0.27-1.fc26.s390x
ykpers-1.18.0-2.fc26.s390x
python3-librepo-1.8.0-1.fc26.s390x
systemtap-runtime-3.2-2.fc26.s390x
geoclue2-2.4.5-4.fc26.s390x
initscripts-9.72-1.fc26.s390x
plymouth-0.9.3-0.7.20160620git0e65b86c.fc26.s390x
ebtables-2.0.10-22.fc26.s390x
gssproxy-0.7.0-9.fc26.s390x
libXext-1.3.3-5.fc26.s390x
mesa-libEGL-17.2.4-2.fc26.s390x
texlive-texlive.infra-bin-svn40312-33.20160520.fc26.2.s390x
texlive-thumbpdf-svn34621.3.16-33.fc26.2.noarch
texlive-carlisle-svn18258.0-33.fc26.2.noarch
texlive-gsftopk-svn40768-33.fc26.2.noarch
texlive-pdftex-svn41149-33.fc26.2.noarch
texlive-crop-svn15878.1.5-33.fc26.2.noarch
texlive-pxfonts-svn15878.0-33.fc26.2.noarch
texlive-enctex-svn34957.0-33.fc26.2.noarch
texlive-kastrup-svn15878.0-33.fc26.2.noarch
texlive-pspicture-svn15878.0-33.fc26.2.noarch
texlive-varwidth-svn24104.0.92-33.fc26.2.noarch
texlive-currfile-svn40725-33.fc26.2.noarch
texlive-pst-grad-svn15878.1.06-33.fc26.2.noarch
texlive-latex-bin-svn41438-33.fc26.2.noarch
texlive-ltxmisc-svn21927.0-33.fc26.2.noarch
lasi-1.1.2-7.fc26.s390x
adwaita-icon-theme-3.24.0-2.fc26.noarch
xz-devel-5.2.3-2.fc26.s390x
xorg-x11-fonts-Type1-7.5-17.fc26.noarch
libXi-devel-1.7.9-2.fc26.s390x
at-spi2-atk-devel-2.24.1-1.fc26.s390x
pango-devel-1.40.12-1.fc26.s390x
libcacard-devel-2.5.3-1.fc26.s390x
libseccomp-devel-2.3.2-1.fc26.s390x
subversion-1.9.7-1.fc26.s390x
sudo-1.8.21p2-1.fc26.s390x
pykickstart-2.35-2.fc26.noarch
e2fsprogs-1.43.4-2.fc26.s390x
libstdc++-static-7.2.1-2.fc26.s390x
libbsd-0.8.3-3.fc26.s390x
c-ares-1.13.0-1.fc26.s390x
python2-pyxdg-0.25-12.fc26.noarch
nss-softokn-freebl-devel-3.34.0-1.0.fc26.s390x
python2-rpkg-1.51-2.fc26.noarch
strace-4.20-1.fc26.s390x
valgrind-3.13.0-12.fc26.s390x
libsss_idmap-1.16.0-4.fc26.s390x
gnutls-c++-3.5.16-4.fc26.s390x
libwayland-server-1.13.0-3.fc26.s390x
dhcp-client-4.3.5-10.fc26.s390x
bind-libs-9.11.1-4.P3.fc26.s390x
man-pages-4.09-4.fc26.noarch
gpg-pubkey-a29cb19c-53bcbba6
quota-nls-4.03-9.fc26.noarch
qt5-srpm-macros-5.8.0-2.fc26.noarch
xz-libs-5.2.3-2.fc26.s390x
gmp-6.1.2-4.fc26.s390x
audit-libs-2.8.1-1.fc26.s390x
file-5.30-11.fc26.s390x
libusbx-1.0.21-2.fc26.s390x
binutils-2.27-28.fc26.s390x
perl-Errno-1.25-395.fc26.s390x
perl-HTTP-Tiny-0.070-2.fc26.noarch
xml-common-0.6.3-45.fc26.noarch
opus-1.2.1-1.fc26.s390x
kernel-devel-4.13.13-200.fc26.s390x
perl-podlators-4.09-2.fc26.noarch
flac-libs-1.3.2-2.fc26.s390x
libacl-devel-2.2.52-15.fc26.s390x
coreutils-common-8.27-7.fc26.s390x
cracklib-2.9.6-5.fc26.s390x
pyliblzma-0.5.3-17.fc26.s390x
libnotify-0.7.7-2.fc26.s390x
python3-idna-2.5-1.fc26.noarch
python3-pyOpenSSL-16.2.0-6.fc26.noarch
python2-pbr-1.10.0-4.fc26.noarch
pyusb-1.0.0-4.fc26.noarch
python2-fedora-0.9.0-6.fc26.noarch
librbd1-10.2.7-2.fc26.s390x
pcre-cpp-8.41-3.fc26.s390x
glibc-devel-2.25-12.fc26.s390x
libnfs-1.9.8-3.fc26.s390x
libsolv-0.6.30-2.fc26.s390x
python3-pycurl-7.43.0-8.fc26.s390x
libyubikey-1.13-3.fc26.s390x
rpmlint-1.10-5.fc26.noarch
python2-pygpgme-0.3-22.fc26.s390x
s390utils-base-1.36.1-3.fc26.s390x
ppp-2.4.7-11.fc26.s390x
s390utils-cpuplugd-1.36.1-3.fc26.s390x
nfs-utils-2.1.1-6.rc6.fc26.s390x
libXrender-0.9.10-2.fc26.s390x
libglvnd-gles-1.0.0-1.fc26.s390x
texlive-texlive.infra-svn41280-33.fc26.2.noarch
texlive-lm-svn28119.2.004-33.fc26.2.noarch
texlive-babelbib-svn25245.1.31-33.fc26.2.noarch
texlive-index-svn24099.4.1beta-33.fc26.2.noarch
texlive-pdftex-bin-svn40987-33.20160520.fc26.2.s390x
texlive-csquotes-svn39538-33.fc26.2.noarch
texlive-rsfs-svn15878.0-33.fc26.2.noarch
texlive-etex-svn37057.0-33.fc26.2.noarch
texlive-knuth-lib-svn35820.0-33.fc26.2.noarch
texlive-pst-math-svn34786.0.63-33.fc26.2.noarch
texlive-utopia-svn15878.0-33.fc26.2.noarch
texlive-eso-pic-svn37925.2.0g-33.fc26.2.noarch
texlive-pst-fill-svn15878.1.01-33.fc26.2.noarch
texlive-latex-bin-bin-svn14050.0-33.20160520.fc26.2.noarch
texlive-jknapltx-svn19440.0-33.fc26.2.noarch
texlive-collection-latexrecommended-svn35765.0-33.20160520.fc26.2.noarch
adwaita-cursor-theme-3.24.0-2.fc26.noarch
xorg-x11-fonts-ISO8859-1-100dpi-7.5-17.fc26.noarch
libXcomposite-devel-0.4.4-9.fc26.s390x
at-spi2-core-devel-2.24.1-1.fc26.s390x
harfbuzz-devel-1.4.4-1.fc26.s390x
rpmdevtools-8.10-2.fc26.noarch
texi2html-5.0-5.fc26.noarch
libnfs-devel-1.9.8-3.fc26.s390x
firewalld-0.4.4.5-1.fc26.noarch
wpa_supplicant-2.6-12.fc26.s390x
systemtap-sdt-devel-3.2-2.fc26.s390x
newt-python-0.52.20-1.fc26.s390x
perl-Mozilla-CA-20160104-4.fc26.noarch
pth-2.0.7-28.fc26.s390x
python3-pyxdg-0.25-12.fc26.noarch
nss-softokn-devel-3.34.0-1.0.fc26.s390x
fedpkg-1.30-4.fc26.noarch
timedatex-0.4-3.fc26.s390x
libjpeg-turbo-1.5.3-1.fc26.s390x
glusterfs-cli-3.10.8-1.fc26.s390x
libsss_nss_idmap-1.16.0-4.fc26.s390x
gdb-8.0.1-33.fc26.s390x
dnf-yum-2.7.5-2.fc26.noarch
perl-Data-Dumper-2.161-3.fc26.s390x
python-async-0.6.1-9.fc22.s390x
poppler-data-0.4.7-7.fc26.noarch
ocaml-srpm-macros-4-2.fc26.noarch
libuuid-2.30.2-1.fc26.s390x
libgpg-error-1.25-2.fc26.s390x
libassuan-2.4.3-2.fc26.s390x
graphite2-1.3.10-1.fc26.s390x
perl-Text-Tabs+Wrap-2013.0523-366.fc26.noarch
perl-Error-0.17024-8.fc26.noarch
which-2.21-2.fc26.s390x
libXau-1.0.8-7.fc26.s390x
orc-0.4.27-1.fc26.s390x
perl-Pod-Perldoc-3.28-1.fc26.noarch
libsndfile-1.0.28-6.fc26.s390x
patch-2.7.5-4.fc26.s390x
gzip-1.8-2.fc26.s390x
python-ipaddress-1.0.16-4.fc26.noarch
yum-metadata-parser-1.1.4-18.fc26.s390x
python3-dbus-1.2.4-6.fc26.s390x
python3-cryptography-2.0.2-2.fc26.s390x
python3-kickstart-2.35-2.fc26.noarch
python2-imagesize-0.7.1-5.fc26.noarch
python2-jinja2-2.9.6-1.fc26.noarch
libradosstriper-devel-10.2.7-2.fc26.s390x
soundtouch-1.9.2-4.fc26.s390x
glibc-headers-2.25-12.fc26.s390x
libndp-1.6-2.fc26.s390x
rpm-4.13.0.2-1.fc26.s390x
rest-0.8.0-2.fc26.s390x
libvisual-0.4.0-21.fc26.s390x
python2-hawkey-0.11.1-1.fc26.s390x
dnf-plugins-core-2.1.5-1.fc26.noarch
fakeroot-libs-1.22-1.fc26.s390x
device-mapper-event-libs-1.02.137-6.fc26.s390x
cyrus-sasl-2.1.26-32.fc26.s390x
kernel-modules-4.13.13-200.fc26.s390x
cronie-anacron-1.5.1-5.fc26.s390x
libpath_utils-0.2.1-34.fc26.s390x
libX11-common-1.6.5-2.fc26.noarch
libXft-2.3.2-5.fc26.s390x
gtk2-2.24.31-4.fc26.s390x
texlive-etoolbox-svn38031.2.2a-33.fc26.2.noarch
texlive-multido-svn18302.1.42-33.fc26.2.noarch
texlive-glyphlist-svn28576.0-33.fc26.2.noarch
texlive-setspace-svn24881.6.7a-33.fc26.2.noarch
texlive-mathtools-svn38833-33.fc26.2.noarch
texlive-ncntrsbk-svn31835.0-33.fc26.2.noarch
texlive-dvisvgm-def-svn41011-33.fc26.2.noarch
texlive-ifetex-svn24853.1.2-33.fc26.2.noarch
texlive-parskip-svn19963.2.0-33.fc26.2.noarch
texlive-bera-svn20031.0-33.fc26.2.noarch
texlive-pgf-svn40966-33.fc26.2.noarch
texlive-auto-pst-pdf-svn23723.0.6-33.fc26.2.noarch
texlive-ctable-svn38672-33.fc26.2.noarch
texlive-typehtml-svn17134.0-33.fc26.2.noarch
mesa-libGLES-17.2.4-2.fc26.s390x
vte291-0.48.4-1.fc26.s390x
libdrm-devel-2.4.88-1.fc26.s390x
libcephfs_jni1-10.2.7-2.fc26.s390x
bzip2-devel-1.0.6-22.fc26.s390x
expat-devel-2.2.4-1.fc26.s390x
libsepol-devel-2.6-2.fc26.s390x
glib2-static-2.52.3-2.fc26.s390x
virglrenderer-devel-0.6.0-1.20170210git76b3da97b.fc26.s390x
yum-utils-1.1.31-512.fc26.noarch
parted-3.2-24.fc26.s390x
python3-beautifulsoup4-4.6.0-1.fc26.noarch
python-bunch-1.0.1-10.fc26.noarch
perl-Time-HiRes-1.9746-1.fc26.s390x
lz4-1.8.0-1.fc26.s390x
nss-util-3.34.0-1.0.fc26.s390x
openssh-clients-7.5p1-4.fc26.s390x
chrony-3.2-1.fc26.s390x
dnf-conf-2.7.5-2.fc26.noarch
glusterfs-server-3.10.8-1.fc26.s390x
sssd-client-1.16.0-4.fc26.s390x
man-db-2.7.6.1-8.fc26.s390x
bodhi-client-2.12.2-3.fc26.noarch
perl-Module-CoreList-5.20171120-1.fc26.noarch
hawkey-0.6.4-3.fc25.s390x
python-srpm-macros-3-20.fc26.noarch
perl-srpm-macros-1-21.fc26.noarch
expat-2.2.4-1.fc26.s390x
chkconfig-1.10-1.fc26.s390x
findutils-4.6.0-12.fc26.s390x
mesa-libwayland-egl-17.2.4-2.fc26.s390x
procps-ng-3.3.10-13.fc26.s390x
mesa-libglapi-17.2.4-2.fc26.s390x
perl-Unicode-Normalize-1.25-366.fc26.s390x
perl-IO-Socket-IP-0.39-1.fc26.noarch
hunspell-en-US-0.20140811.1-6.fc26.noarch
libxcb-1.12-3.fc26.s390x
libgo-devel-7.2.1-2.fc26.s390x
perl-Pod-Escapes-1.07-366.fc26.noarch
perl-Pod-Usage-1.69-2.fc26.noarch
libtheora-1.1.1-15.fc26.s390x
tcp_wrappers-7.6-85.fc26.s390x
coreutils-8.27-7.fc26.s390x
libmount-2.30.2-1.fc26.s390x
python2-iniparse-0.4-24.fc26.noarch
python2-decorator-4.0.11-2.fc26.noarch
ModemManager-glib-1.6.10-1.fc26.s390x
python3-decorator-4.0.11-2.fc26.noarch
python3-cffi-1.9.1-2.fc26.s390x
python-bugzilla-cli-2.1.0-1.fc26.noarch
python2-funcsigs-1.0.2-5.fc26.noarch
python2-babel-2.3.4-5.fc26.noarch
python-bugzilla-2.1.0-1.fc26.noarch
libradosstriper1-10.2.7-2.fc26.s390x
snappy-1.1.4-3.fc26.s390x
dtc-1.4.5-1.fc26.s390x
libmpcdec-1.2.6-17.fc26.s390x
rpm-libs-4.13.0.2-1.fc26.s390x
python-urlgrabber-3.10.1-11.fc26.noarch
sysfsutils-2.1.0-20.fc26.s390x
python3-hawkey-0.11.1-1.fc26.s390x
python3-dnf-plugins-core-2.1.5-1.fc26.noarch
ethtool-4.13-1.fc26.s390x
iputils-20161105-5.fc26.s390x
plymouth-scripts-0.9.3-0.7.20160620git0e65b86c.fc26.s390x
cronie-1.5.1-5.fc26.s390x
libini_config-1.3.1-34.fc26.s390x
libX11-1.6.5-2.fc26.s390x
libglvnd-egl-1.0.0-1.fc26.s390x
texlive-kpathsea-svn41139-33.fc26.2.noarch
texlive-thumbpdf-bin-svn6898.0-33.20160520.fc26.2.noarch
texlive-subfig-svn15878.1.3-33.fc26.2.noarch
texlive-gsftopk-bin-svn40473-33.20160520.fc26.2.s390x
texlive-tex-ini-files-svn40533-33.fc26.2.noarch
texlive-qstest-svn15878.0-33.fc26.2.noarch
texlive-palatino-svn31835.0-33.fc26.2.noarch
texlive-ec-svn25033.1.0-33.fc26.2.noarch
texlive-iftex-svn29654.0.2-33.fc26.2.noarch
texlive-pslatex-svn16416.0-33.fc26.2.noarch
texlive-algorithms-svn38085.0.1-33.fc26.2.noarch
texlive-filehook-svn24280.0.5d-33.fc26.2.noarch
texlive-pst-node-svn40743-33.fc26.2.noarch
texlive-rotating-svn16832.2.16b-33.fc26.2.noarch
texlive-seminar-svn34011.1.62-33.fc26.2.noarch
gtk3-3.22.21-2.fc26.s390x
libuuid-devel-2.30.2-1.fc26.s390x
java-1.8.0-openjdk-1.8.0.151-1.b12.fc26.s390x
libXinerama-devel-1.1.3-7.fc26.s390x
emacs-common-25.3-3.fc26.s390x
gtk3-devel-3.22.21-2.fc26.s390x
fedora-packager-0.6.0.1-2.fc26.noarch
libxml2-devel-2.9.4-2.fc26.s390x
snappy-devel-1.1.4-3.fc26.s390x
python2-dnf-plugin-migrate-2.1.5-1.fc26.noarch
authconfig-7.0.1-2.fc26.s390x
newt-python3-0.52.20-1.fc26.s390x
python-decoratortools-1.8-13.fc26.noarch
python-systemd-doc-234-1.fc26.s390x
openssl-libs-1.1.0g-1.fc26.s390x
git-core-2.13.6-2.fc26.s390x
python3-dnf-plugin-system-upgrade-2.0.4-1.fc26.noarch
glusterfs-libs-3.10.8-1.fc26.s390x
ca-certificates-2017.2.20-1.0.fc26.noarch
unbound-libs-1.6.7-1.fc26.s390x
libsss_certmap-1.16.0-4.fc26.s390x
glusterfs-api-devel-3.10.8-1.fc26.s390x
selinux-policy-targeted-3.13.1-260.17.fc26.noarch
publicsuffix-list-dafsa-20171028-1.fc26.noarch
gpg-pubkey-a0a7badb-52844296
gpg-pubkey-e372e838-56fd7943
gpg-pubkey-3b921d09-57a87096
google-roboto-slab-fonts-1.100263-0.5.20150923git.fc26.noarch
libreport-filesystem-2.9.1-3.fc26.s390x
glibc-all-langpacks-2.25-12.fc26.s390x
libcom_err-1.43.4-2.fc26.s390x
libffi-3.1-12.fc26.s390x
keyutils-libs-1.5.10-1.fc26.s390x
diffutils-3.5-3.fc26.s390x
apr-util-1.5.4-6.fc26.s390x
bluez-libs-5.46-6.fc26.s390x
libksba-1.3.5-3.fc26.s390x
ncurses-6.0-8.20170212.fc26.s390x
gsm-1.0.17-1.fc26.s390x
libteam-1.27-1.fc26.s390x
perl-Fedora-VSP-0.001-5.fc26.noarch
libusb-0.1.5-8.fc26.s390x
acl-2.2.52-15.fc26.s390x
dwz-0.12-3.fc26.s390x
libblkid-2.30.2-1.fc26.s390x
polkit-libs-0.113-8.fc26.s390x
dbus-python-1.2.4-6.fc26.s390x
gts-0.7.6-30.20121130.fc26.s390x
libfdisk-2.30.2-1.fc26.s390x
python3-pycparser-2.14-10.fc26.noarch
python3-bugzilla-2.1.0-1.fc26.noarch
python2-docutils-0.13.1-4.fc26.noarch
pytz-2016.10-4.fc26.noarch
python2-requests-2.13.0-1.fc26.noarch
libcephfs-devel-10.2.7-2.fc26.s390x
ncurses-c++-libs-6.0-8.20170212.fc26.s390x
GeoIP-1.6.11-1.fc26.s390x
liblockfile-1.09-5.fc26.s390x
rpm-plugin-selinux-4.13.0.2-1.fc26.s390x
systemtap-devel-3.2-2.fc26.s390x
libsysfs-2.1.0-20.fc26.s390x
libdnf-0.11.1-1.fc26.s390x
libgfortran-7.2.1-2.fc26.s390x
mesa-libgbm-17.2.4-2.fc26.s390x
dracut-046-3.1.fc26.s390x
lvm2-libs-2.02.168-6.fc26.s390x
libXfixes-5.0.3-2.fc26.s390x
brlapi-0.6.6-5.fc26.s390x
texlive-metafont-svn40793-33.fc26.2.noarch
texlive-graphics-cfg-svn40269-33.fc26.2.noarch
texlive-mptopdf-svn41282-33.fc26.2.noarch
texlive-makeindex-bin-svn40473-33.20160520.fc26.2.s390x
texlive-texlive-scripts-bin-svn29741.0-33.20160520.fc26.2.noarch
texlive-sauerj-svn15878.0-33.fc26.2.noarch
texlive-txfonts-svn15878.0-33.fc26.2.noarch
texlive-filecontents-svn24250.1.3-33.fc26.2.noarch
texlive-lualibs-svn40370-33.fc26.2.noarch
texlive-section-svn20180.0-33.fc26.2.noarch
texlive-ucharcat-svn38907-33.fc26.2.noarch
texlive-hyperref-svn41396-33.fc26.2.noarch
texlive-pst-3d-svn17257.1.10-33.fc26.2.noarch
texlive-oberdiek-svn41346-33.fc26.2.noarch
texlive-ae-svn15878.1.4-33.fc26.2.noarch
texlive-collection-basic-svn41149-33.20160520.fc26.2.noarch
gnat-srpm-macros-4-2.fc26.noarch
glib2-devel-2.52.3-2.fc26.s390x
netpbm-progs-10.80.00-2.fc26.s390x
libXxf86vm-devel-1.1.4-4.fc26.s390x
nettle-devel-3.3-2.fc26.s390x
cairo-gobject-devel-1.14.10-1.fc26.s390x
fedora-rpm-macros-26-2.fc26.noarch
elfutils-devel-0.169-1.fc26.s390x
libidn-devel-1.33-2.fc26.s390x
s390utils-1.36.1-3.fc26.s390x
gcc-gfortran-7.2.1-2.fc26.s390x
libtool-2.4.6-17.fc26.s390x
python3-cssselect-0.9.2-4.fc26.noarch
python2-cssselect-0.9.2-4.fc26.noarch
bison-3.0.4-6.fc26.s390x
rootfiles-8.1-20.fc26.noarch
git-core-doc-2.13.6-2.fc26.s390x
vim-enhanced-8.0.1360-1.fc26.s390x
glusterfs-3.10.8-1.fc26.s390x
boost-system-1.63.0-10.fc26.s390x
gnutls-dane-3.5.16-4.fc26.s390x
pkgconf-m4-1.3.12-1.fc26.noarch
libcurl-devel-7.53.1-13.fc26.s390x
python3-urllib3-1.20-2.fc26.noarch
libsss_autofs-1.16.0-4.fc26.s390x
=== TEST BEGIN ===
Using CC: /home/fam/bin/cc
Install prefix /var/tmp/patchew-tester-tmp-oqq3slb3/src/install
BIOS directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/share/qemu
firmware path /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/share/qemu-firmware
binary directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/bin
library directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/lib
module directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/lib/qemu
libexec directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/libexec
include directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/include
config directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/etc
local state directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/var
Manual directory /var/tmp/patchew-tester-tmp-oqq3slb3/src/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /var/tmp/patchew-tester-tmp-oqq3slb3/src
GIT binary git
GIT submodules ui/keycodemapdb capstone
C compiler /home/fam/bin/cc
Host C compiler cc
C++ compiler c++
Objective-C compiler /home/fam/bin/cc
ARFLAGS rv
CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -DHAS_LIBSSH2_SFTP_FSYNC -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DNCURSES_WIDECHAR -D_GNU_SOURCE -D_DEFAULT_SOURCE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1 -I/usr/include/libpng16 -I/usr/include/libdrm -I$(SRC_PATH)/capstone/include
LDFLAGS -Wl,--warn-common -m64 -g
make make
install install
python python -B
smbd /usr/sbin/smbd
module support no
host CPU s390x
host big endian yes
target list aarch64-softmmu alpha-softmmu arm-softmmu cris-softmmu hppa-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblazeel-softmmu microblaze-softmmu mips64el-softmmu mips64-softmmu mipsel-softmmu mips-softmmu moxie-softmmu nios2-softmmu or1k-softmmu ppc64-softmmu ppcemb-softmmu ppc-softmmu s390x-softmmu sh4eb-softmmu sh4-softmmu sparc64-softmmu sparc-softmmu tricore-softmmu unicore32-softmmu x86_64-softmmu xtensaeb-softmmu xtensa-softmmu aarch64_be-linux-user aarch64-linux-user alpha-linux-user armeb-linux-user arm-linux-user cris-linux-user hppa-linux-user i386-linux-user m68k-linux-user microblazeel-linux-user microblaze-linux-user mips64el-linux-user mips64-linux-user mipsel-linux-user mips-linux-user mipsn32el-linux-user mipsn32-linux-user nios2-linux-user or1k-linux-user ppc64abi32-linux-user ppc64le-linux-user ppc64-linux-user ppc-linux-user s390x-linux-user sh4eb-linux-user sh4-linux-user sparc32plus-linux-user sparc64-linux-user sparc-linux-user tilegx-linux-user x86_64-linux-user
gprof enabled no
sparse enabled no
strip binaries yes
profiler no
static build no
SDL support yes (2.0.7)
GTK support yes (3.22.21)
GTK GL support yes
VTE support yes (0.48.4)
TLS priority NORMAL
GNUTLS support yes
GNUTLS rnd yes
libgcrypt no
libgcrypt kdf no
nettle yes (3.3)
nettle kdf yes
libtasn1 yes
curses support yes
virgl support yes
curl support yes
mingw32 support no
Audio drivers oss
Block whitelist (rw)
Block whitelist (ro)
VirtFS support yes
Multipath support no
VNC support yes
VNC SASL support yes
VNC JPEG support yes
VNC PNG support yes
xen support no
brlapi support yes
bluez support yes
Documentation yes
PIE no
vde support no
netmap support no
Linux AIO support yes
ATTR/XATTR support yes
Install blobs yes
KVM support yes
HAX support no
HVF support no
WHPX support no
TCG support yes
TCG debug enabled no
TCG interpreter no
malloc trim support yes
RDMA support no
fdt support yes
preadv support yes
fdatasync yes
madvise yes
posix_madvise yes
libcap-ng support yes
vhost-net support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backends log
spice support no
rbd support yes
xfsctl support no
smartcard support yes
libusb yes
usb net redir yes
OpenGL support yes
OpenGL dmabufs yes
libiscsi support yes
libnfs support yes
build guest agent yes
QGA VSS support no
QGA w32 disk info no
QGA MSI support no
seccomp support yes
coroutine backend ucontext
coroutine pool yes
debug stack usage no
crypto afalg no
GlusterFS support yes
gcov gcov
gcov enabled no
TPM support yes
libssh2 support yes
TPM passthrough no
TPM emulator yes
QOM debugging yes
Live block migration yes
lzo support yes
snappy support yes
bzip2 support yes
NUMA host support no
libxml2 yes
tcmalloc support no
jemalloc support no
avx2 optimization no
replication support yes
VxHS block device no
capstone git
GEN aarch64-softmmu/config-devices.mak.tmp
GEN alpha-softmmu/config-devices.mak.tmp
GEN arm-softmmu/config-devices.mak.tmp
GEN cris-softmmu/config-devices.mak.tmp
GEN cris-softmmu/config-devices.mak
GEN alpha-softmmu/config-devices.mak
GEN arm-softmmu/config-devices.mak
GEN aarch64-softmmu/config-devices.mak
GEN hppa-softmmu/config-devices.mak.tmp
GEN i386-softmmu/config-devices.mak.tmp
GEN lm32-softmmu/config-devices.mak.tmp
GEN m68k-softmmu/config-devices.mak.tmp
GEN lm32-softmmu/config-devices.mak
GEN m68k-softmmu/config-devices.mak
GEN microblazeel-softmmu/config-devices.mak.tmp
GEN microblaze-softmmu/config-devices.mak.tmp
GEN hppa-softmmu/config-devices.mak
GEN i386-softmmu/config-devices.mak
GEN mips64el-softmmu/config-devices.mak.tmp
GEN mips64-softmmu/config-devices.mak.tmp
GEN microblaze-softmmu/config-devices.mak
GEN mipsel-softmmu/config-devices.mak.tmp
GEN microblazeel-softmmu/config-devices.mak
GEN mips-softmmu/config-devices.mak.tmp
GEN mips64el-softmmu/config-devices.mak
GEN mips64-softmmu/config-devices.mak
GEN moxie-softmmu/config-devices.mak.tmp
GEN nios2-softmmu/config-devices.mak.tmp
GEN mips-softmmu/config-devices.mak
GEN mipsel-softmmu/config-devices.mak
GEN or1k-softmmu/config-devices.mak.tmp
GEN moxie-softmmu/config-devices.mak
GEN nios2-softmmu/config-devices.mak
GEN ppc64-softmmu/config-devices.mak.tmp
GEN ppcemb-softmmu/config-devices.mak.tmp
GEN ppc-softmmu/config-devices.mak.tmp
GEN or1k-softmmu/config-devices.mak
GEN s390x-softmmu/config-devices.mak.tmp
GEN s390x-softmmu/config-devices.mak
GEN ppcemb-softmmu/config-devices.mak
GEN ppc-softmmu/config-devices.mak
GEN ppc64-softmmu/config-devices.mak
GEN sh4eb-softmmu/config-devices.mak.tmp
GEN sh4-softmmu/config-devices.mak.tmp
GEN sparc64-softmmu/config-devices.mak.tmp
GEN sparc-softmmu/config-devices.mak.tmp
GEN sparc-softmmu/config-devices.mak
GEN sh4-softmmu/config-devices.mak
GEN tricore-softmmu/config-devices.mak.tmp
GEN sh4eb-softmmu/config-devices.mak
GEN unicore32-softmmu/config-devices.mak.tmp
GEN x86_64-softmmu/config-devices.mak.tmp
GEN sparc64-softmmu/config-devices.mak
GEN xtensaeb-softmmu/config-devices.mak.tmp
GEN tricore-softmmu/config-devices.mak
GEN unicore32-softmmu/config-devices.mak
GEN xtensa-softmmu/config-devices.mak.tmp
GEN aarch64_be-linux-user/config-devices.mak.tmp
GEN xtensaeb-softmmu/config-devices.mak
GEN x86_64-softmmu/config-devices.mak
GEN aarch64-linux-user/config-devices.mak.tmp
GEN alpha-linux-user/config-devices.mak.tmp
GEN xtensa-softmmu/config-devices.mak
GEN aarch64_be-linux-user/config-devices.mak
GEN armeb-linux-user/config-devices.mak.tmp
GEN arm-linux-user/config-devices.mak.tmp
GEN aarch64-linux-user/config-devices.mak
GEN alpha-linux-user/config-devices.mak
GEN cris-linux-user/config-devices.mak.tmp
GEN hppa-linux-user/config-devices.mak.tmp
GEN arm-linux-user/config-devices.mak
GEN armeb-linux-user/config-devices.mak
GEN i386-linux-user/config-devices.mak.tmp
GEN m68k-linux-user/config-devices.mak.tmp
GEN cris-linux-user/config-devices.mak
GEN hppa-linux-user/config-devices.mak
GEN microblazeel-linux-user/config-devices.mak.tmp
GEN microblaze-linux-user/config-devices.mak.tmp
GEN m68k-linux-user/config-devices.mak
GEN i386-linux-user/config-devices.mak
GEN mips64-linux-user/config-devices.mak.tmp
GEN mips64el-linux-user/config-devices.mak.tmp
GEN microblaze-linux-user/config-devices.mak
GEN mipsel-linux-user/config-devices.mak.tmp
GEN microblazeel-linux-user/config-devices.mak
GEN mips64-linux-user/config-devices.mak
GEN mips64el-linux-user/config-devices.mak
GEN mips-linux-user/config-devices.mak.tmp
GEN mipsn32el-linux-user/config-devices.mak.tmp
GEN mipsel-linux-user/config-devices.mak
GEN mipsn32-linux-user/config-devices.mak.tmp
GEN nios2-linux-user/config-devices.mak.tmp
GEN mipsn32el-linux-user/config-devices.mak
GEN or1k-linux-user/config-devices.mak.tmp
GEN mips-linux-user/config-devices.mak
GEN nios2-linux-user/config-devices.mak
GEN ppc64abi32-linux-user/config-devices.mak.tmp
GEN mipsn32-linux-user/config-devices.mak
GEN ppc64le-linux-user/config-devices.mak.tmp
GEN ppc64-linux-user/config-devices.mak.tmp
GEN or1k-linux-user/config-devices.mak
GEN ppc-linux-user/config-devices.mak.tmp
GEN ppc64abi32-linux-user/config-devices.mak
GEN ppc64le-linux-user/config-devices.mak
GEN s390x-linux-user/config-devices.mak.tmp
GEN sh4eb-linux-user/config-devices.mak.tmp
GEN ppc64-linux-user/config-devices.mak
GEN ppc-linux-user/config-devices.mak
GEN sh4-linux-user/config-devices.mak.tmp
GEN sparc32plus-linux-user/config-devices.mak.tmp
GEN s390x-linux-user/config-devices.mak
GEN sh4eb-linux-user/config-devices.mak
GEN sh4-linux-user/config-devices.mak
GEN sparc32plus-linux-user/config-devices.mak
GEN sparc64-linux-user/config-devices.mak.tmp
GEN sparc-linux-user/config-devices.mak.tmp
GEN tilegx-linux-user/config-devices.mak.tmp
GEN x86_64-linux-user/config-devices.mak.tmp
GEN sparc-linux-user/config-devices.mak
GEN sparc64-linux-user/config-devices.mak
GEN tilegx-linux-user/config-devices.mak
GEN x86_64-linux-user/config-devices.mak
GEN config-host.h
GIT ui/keycodemapdb capstone
GEN qemu-options.def
GEN qmp-commands.h
GEN qapi-types.h
GEN qapi-visit.h
Submodule 'capstone' (git://git.qemu.org/capstone.git) registered for path 'capstone'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered for path 'ui/keycodemapdb'
Cloning into '/var/tmp/patchew-tester-tmp-oqq3slb3/src/capstone'...
GEN qapi-event.h
GEN qmp-marshal.c
GEN qapi-types.c
GEN qapi-visit.c
GEN qapi-event.c
GEN qmp-introspect.h
GEN qmp-introspect.c
GEN trace/generated-tcg-tracers.h
GEN trace/generated-helpers-wrappers.h
GEN trace/generated-helpers.h
GEN trace/generated-helpers.c
GEN module_block.h
GEN tests/test-qapi-types.h
GEN tests/test-qapi-visit.h
GEN tests/test-qmp-commands.h
GEN tests/test-qapi-event.h
GEN tests/test-qmp-introspect.h
GEN trace-root.h
GEN util/trace.h
GEN crypto/trace.h
GEN io/trace.h
GEN migration/trace.h
GEN block/trace.h
GEN chardev/trace.h
GEN hw/block/trace.h
GEN hw/block/dataplane/trace.h
GEN hw/char/trace.h
GEN hw/intc/trace.h
GEN hw/net/trace.h
GEN hw/virtio/trace.h
GEN hw/audio/trace.h
GEN hw/misc/trace.h
GEN hw/usb/trace.h
GEN hw/scsi/trace.h
GEN hw/nvram/trace.h
GEN hw/display/trace.h
GEN hw/input/trace.h
GEN hw/timer/trace.h
GEN hw/dma/trace.h
GEN hw/sparc/trace.h
GEN hw/sparc64/trace.h
GEN hw/sd/trace.h
GEN hw/isa/trace.h
GEN hw/mem/trace.h
GEN hw/i386/trace.h
GEN hw/i386/xen/trace.h
GEN hw/9pfs/trace.h
GEN hw/ppc/trace.h
GEN hw/pci/trace.h
GEN hw/pci-host/trace.h
GEN hw/s390x/trace.h
GEN hw/vfio/trace.h
GEN hw/acpi/trace.h
GEN hw/arm/trace.h
GEN hw/alpha/trace.h
GEN hw/hppa/trace.h
GEN hw/xen/trace.h
GEN hw/ide/trace.h
GEN ui/trace.h
GEN audio/trace.h
GEN net/trace.h
GEN target/arm/trace.h
GEN target/i386/trace.h
GEN target/mips/trace.h
GEN target/sparc/trace.h
GEN target/s390x/trace.h
GEN target/ppc/trace.h
GEN qom/trace.h
GEN linux-user/trace.h
GEN qapi/trace.h
GEN accel/tcg/trace.h
GEN accel/kvm/trace.h
GEN nbd/trace.h
GEN scsi/trace.h
GEN trace-root.c
GEN util/trace.c
GEN crypto/trace.c
GEN io/trace.c
GEN migration/trace.c
GEN block/trace.c
GEN chardev/trace.c
GEN hw/block/trace.c
GEN hw/block/dataplane/trace.c
GEN hw/char/trace.c
GEN hw/intc/trace.c
GEN hw/net/trace.c
GEN hw/virtio/trace.c
GEN hw/audio/trace.c
GEN hw/misc/trace.c
GEN hw/usb/trace.c
GEN hw/scsi/trace.c
GEN hw/nvram/trace.c
GEN hw/display/trace.c
GEN hw/input/trace.c
GEN hw/timer/trace.c
GEN hw/dma/trace.c
GEN hw/sparc/trace.c
GEN hw/sparc64/trace.c
GEN hw/sd/trace.c
GEN hw/isa/trace.c
GEN hw/mem/trace.c
GEN hw/i386/trace.c
GEN hw/i386/xen/trace.c
GEN hw/9pfs/trace.c
GEN hw/ppc/trace.c
GEN hw/pci/trace.c
GEN hw/pci-host/trace.c
GEN hw/s390x/trace.c
GEN hw/vfio/trace.c
GEN hw/acpi/trace.c
GEN hw/arm/trace.c
GEN hw/alpha/trace.c
GEN hw/hppa/trace.c
GEN hw/xen/trace.c
GEN hw/ide/trace.c
GEN ui/trace.c
GEN audio/trace.c
GEN net/trace.c
GEN target/arm/trace.c
GEN target/i386/trace.c
GEN target/mips/trace.c
GEN target/sparc/trace.c
GEN target/s390x/trace.c
GEN target/ppc/trace.c
GEN qom/trace.c
GEN linux-user/trace.c
GEN qapi/trace.c
GEN accel/tcg/trace.c
GEN accel/kvm/trace.c
GEN nbd/trace.c
GEN scsi/trace.c
GEN config-all-devices.mak
Cloning into '/var/tmp/patchew-tester-tmp-oqq3slb3/src/ui/keycodemapdb'...
GEN ui/input-keymap-atset1-to-qcode.c
GEN ui/input-keymap-linux-to-qcode.c
GEN ui/input-keymap-qcode-to-atset1.c
CC cs.o
GEN ui/input-keymap-qcode-to-atset2.c
GEN ui/input-keymap-qcode-to-atset3.c
GEN ui/input-keymap-qcode-to-linux.c
CC utils.o
GEN ui/input-keymap-qcode-to-qnum.c
GEN ui/input-keymap-qcode-to-sun.c
GEN ui/input-keymap-qnum-to-qcode.c
GEN ui/input-keymap-usb-to-qcode.c
GEN ui/input-keymap-win32-to-qcode.c
GEN ui/input-keymap-x11-to-qcode.c
GEN ui/input-keymap-xorgevdev-to-qcode.c
GEN ui/input-keymap-xorgkbd-to-qcode.c
GEN ui/input-keymap-xorgxquartz-to-qcode.c
GEN ui/input-keymap-xorgxwin-to-qcode.c
CC SStream.o
CC MCInstrDesc.o
CC MCRegisterInfo.o
CC arch/ARM/ARMDisassembler.o
CC arch/ARM/ARMInstPrinter.o
CC arch/ARM/ARMMapping.o
CC arch/ARM/ARMModule.o
CC arch/AArch64/AArch64BaseInfo.o
CC arch/AArch64/AArch64Disassembler.o
CC arch/AArch64/AArch64InstPrinter.o
CC arch/AArch64/AArch64Mapping.o
CC arch/AArch64/AArch64Module.o
CC arch/Mips/MipsDisassembler.o
CC arch/Mips/MipsInstPrinter.o
CC arch/Mips/MipsMapping.o
CC arch/Mips/MipsModule.o
CC arch/PowerPC/PPCDisassembler.o
CC arch/PowerPC/PPCInstPrinter.o
CC arch/PowerPC/PPCMapping.o
CC arch/PowerPC/PPCModule.o
CC arch/Sparc/SparcDisassembler.o
CC arch/Sparc/SparcInstPrinter.o
CC arch/Sparc/SparcMapping.o
CC arch/Sparc/SparcModule.o
CC arch/SystemZ/SystemZDisassembler.o
CC arch/SystemZ/SystemZInstPrinter.o
CC arch/SystemZ/SystemZMapping.o
CC arch/SystemZ/SystemZModule.o
CC arch/SystemZ/SystemZMCTargetDesc.o
CC arch/X86/X86DisassemblerDecoder.o
CC arch/X86/X86Disassembler.o
CC arch/X86/X86IntelInstPrinter.o
CC arch/X86/X86ATTInstPrinter.o
CC arch/X86/X86Mapping.o
CC arch/X86/X86Module.o
CC arch/XCore/XCoreDisassembler.o
CC arch/XCore/XCoreInstPrinter.o
CC arch/XCore/XCoreMapping.o
CC arch/XCore/XCoreModule.o
CC MCInst.o
AR libcapstone.a
ar: creating /var/tmp/patchew-tester-tmp-oqq3slb3/src/build/capstone/libcapstone.a
GEN docs/version.texi
GEN qemu-options.texi
CC tests/qemu-iotests/socket_scm_helper.o
GEN qemu-monitor.texi
GEN qemu-img-cmds.texi
GEN qemu-monitor-info.texi
GEN qemu-img.1
GEN qemu-nbd.8
GEN qemu-ga.8
GEN docs/interop/qemu-qmp-qapi.texi
GEN docs/interop/qemu-ga-qapi.texi
GEN docs/qemu-block-drivers.7
GEN fsdev/virtfs-proxy-helper.1
GEN qga/qapi-generated/qga-qapi-types.h
GEN qga/qapi-generated/qga-qapi-visit.h
GEN qga/qapi-generated/qga-qmp-commands.h
GEN qga/qapi-generated/qga-qapi-types.c
GEN qga/qapi-generated/qga-qapi-visit.c
GEN qga/qapi-generated/qga-qmp-marshal.c
CC qmp-introspect.o
CC qapi-types.o
CC qapi-visit.o
CC qapi-event.o
CC qapi/qapi-visit-core.o
CC qapi/qapi-dealloc-visitor.o
CC qapi/qobject-input-visitor.o
CC qapi/qobject-output-visitor.o
CC qapi/qmp-registry.o
CC qapi/qmp-dispatch.o
CC qapi/string-input-visitor.o
CC qapi/string-output-visitor.o
CC qapi/opts-visitor.o
CC qapi/qapi-clone-visitor.o
CC qapi/qmp-event.o
CC qapi/qapi-util.o
CC qobject/qnull.o
CC qobject/qnum.o
CC qobject/qstring.o
CC qobject/qdict.o
CC qobject/qlist.o
CC qobject/qbool.o
CC qobject/qlit.o
CC qobject/qjson.o
CC qobject/qobject.o
CC qobject/json-lexer.o
CC qobject/json-streamer.o
CC qobject/json-parser.o
CC trace/control.o
CC trace/qmp.o
CC util/osdep.o
CC util/cutils.o
CC util/unicode.o
CC util/qemu-timer-common.o
CC util/bufferiszero.o
CC util/lockcnt.o
CC util/aiocb.o
CC util/async.o
In file included from /usr/include/sys/syscall.h:24:0,
from /var/tmp/patchew-tester-tmp-oqq3slb3/src/include/qemu/futex.h:17,
from /var/tmp/patchew-tester-tmp-oqq3slb3/src/util/lockcnt.c:15:
/var/tmp/patchew-tester-tmp-oqq3slb3/src/build/linux-headers/asm/unistd.h:12:10: fatal error: asm/unistd_64.h: No such file or directory
#include <asm/unistd_64.h>
^~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [/var/tmp/patchew-tester-tmp-oqq3slb3/src/rules.mak:66: util/lockcnt.o] Error 1
make: *** Waiting for unfinished jobs....
=== OUTPUT END ===
Test command exited with code: 2
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR
2018-02-09 7:54 [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
` (4 preceding siblings ...)
2018-02-09 8:04 ` [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR no-reply
@ 2018-02-09 8:05 ` no-reply
5 siblings, 0 replies; 34+ messages in thread
From: no-reply @ 2018-02-09 8:05 UTC (permalink / raw)
To: aik; +Cc: famz, qemu-devel, alex.williamson, qemu-ppc, david
Hi,
This series failed docker-mingw@fedora build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180209075503.16996-1-aik@ozlabs.ru
Subject: [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR
=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-mingw@fedora
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
364588cdea ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices
b35d106f4a vfio-pci: Allow mmap of MSIX BAR
7144306422 vfio/pci: Relax DMA map errors for MMIO regions
8b136cea18 linux-headers: update to f1517df8701c
=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-xq_0lpqh/src/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
BUILD fedora
GEN /var/tmp/patchew-tester-tmp-xq_0lpqh/src/docker-src.2018-02-09-03.04.00.26226/qemu.tar
Cloning into '/var/tmp/patchew-tester-tmp-xq_0lpqh/src/docker-src.2018-02-09-03.04.00.26226/qemu.tar.vroot'...
done.
Checking out files: 46% (2709/5788)
Checking out files: 47% (2721/5788)
Checking out files: 48% (2779/5788)
Checking out files: 49% (2837/5788)
Checking out files: 50% (2894/5788)
Checking out files: 51% (2952/5788)
Checking out files: 52% (3010/5788)
Checking out files: 53% (3068/5788)
Checking out files: 54% (3126/5788)
Checking out files: 55% (3184/5788)
Checking out files: 56% (3242/5788)
Checking out files: 57% (3300/5788)
Checking out files: 58% (3358/5788)
Checking out files: 59% (3415/5788)
Checking out files: 60% (3473/5788)
Checking out files: 61% (3531/5788)
Checking out files: 62% (3589/5788)
Checking out files: 63% (3647/5788)
Checking out files: 64% (3705/5788)
Checking out files: 65% (3763/5788)
Checking out files: 66% (3821/5788)
Checking out files: 67% (3878/5788)
Checking out files: 68% (3936/5788)
Checking out files: 69% (3994/5788)
Checking out files: 70% (4052/5788)
Checking out files: 71% (4110/5788)
Checking out files: 72% (4168/5788)
Checking out files: 73% (4226/5788)
Checking out files: 74% (4284/5788)
Checking out files: 75% (4341/5788)
Checking out files: 76% (4399/5788)
Checking out files: 77% (4457/5788)
Checking out files: 78% (4515/5788)
Checking out files: 79% (4573/5788)
Checking out files: 80% (4631/5788)
Checking out files: 81% (4689/5788)
Checking out files: 82% (4747/5788)
Checking out files: 83% (4805/5788)
Checking out files: 84% (4862/5788)
Checking out files: 85% (4920/5788)
Checking out files: 86% (4978/5788)
Checking out files: 87% (5036/5788)
Checking out files: 88% (5094/5788)
Checking out files: 89% (5152/5788)
Checking out files: 90% (5210/5788)
Checking out files: 91% (5268/5788)
Checking out files: 92% (5325/5788)
Checking out files: 92% (5365/5788)
Checking out files: 93% (5383/5788)
Checking out files: 94% (5441/5788)
Checking out files: 95% (5499/5788)
Checking out files: 96% (5557/5788)
Checking out files: 97% (5615/5788)
Checking out files: 98% (5673/5788)
Checking out files: 99% (5731/5788)
Checking out files: 100% (5788/5788)
Checking out files: 100% (5788/5788), done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-xq_0lpqh/src/docker-src.2018-02-09-03.04.00.26226/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered for path 'ui/keycodemapdb'
Cloning into '/var/tmp/patchew-tester-tmp-xq_0lpqh/src/docker-src.2018-02-09-03.04.00.26226/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out '6b3d716e2b6472eb7189d3220552280ef3d832ce'
COPY RUNNER
RUN test-mingw in qemu:fedora
Packages installed:
PyYAML-3.12-5.fc27.x86_64
SDL-devel-1.2.15-29.fc27.x86_64
bc-1.07.1-3.fc27.x86_64
bison-3.0.4-8.fc27.x86_64
bzip2-1.0.6-24.fc27.x86_64
ccache-3.3.5-1.fc27.x86_64
clang-5.0.1-1.fc27.x86_64
findutils-4.6.0-14.fc27.x86_64
flex-2.6.1-5.fc27.x86_64
gcc-7.3.1-2.fc27.x86_64
gcc-c++-7.3.1-2.fc27.x86_64
gettext-0.19.8.1-12.fc27.x86_64
git-2.14.3-2.fc27.x86_64
glib2-devel-2.54.3-2.fc27.x86_64
hostname-3.18-4.fc27.x86_64
libaio-devel-0.3.110-9.fc27.x86_64
libasan-7.3.1-2.fc27.x86_64
libfdt-devel-1.4.6-1.fc27.x86_64
libubsan-7.3.1-2.fc27.x86_64
make-4.2.1-4.fc27.x86_64
mingw32-SDL-1.2.15-9.fc27.noarch
mingw32-bzip2-1.0.6-9.fc27.noarch
mingw32-curl-7.54.1-2.fc27.noarch
mingw32-glib2-2.54.1-1.fc27.noarch
mingw32-gmp-6.1.2-2.fc27.noarch
mingw32-gnutls-3.5.13-2.fc27.noarch
mingw32-gtk2-2.24.31-4.fc27.noarch
mingw32-gtk3-3.22.16-1.fc27.noarch
mingw32-libjpeg-turbo-1.5.1-3.fc27.noarch
mingw32-libpng-1.6.29-2.fc27.noarch
mingw32-libssh2-1.8.0-3.fc27.noarch
mingw32-libtasn1-4.13-1.fc27.noarch
mingw32-nettle-3.3-3.fc27.noarch
mingw32-pixman-0.34.0-3.fc27.noarch
mingw32-pkg-config-0.28-9.fc27.x86_64
mingw64-SDL-1.2.15-9.fc27.noarch
mingw64-bzip2-1.0.6-9.fc27.noarch
mingw64-curl-7.54.1-2.fc27.noarch
mingw64-glib2-2.54.1-1.fc27.noarch
mingw64-gmp-6.1.2-2.fc27.noarch
mingw64-gnutls-3.5.13-2.fc27.noarch
mingw64-gtk2-2.24.31-4.fc27.noarch
mingw64-gtk3-3.22.16-1.fc27.noarch
mingw64-libjpeg-turbo-1.5.1-3.fc27.noarch
mingw64-libpng-1.6.29-2.fc27.noarch
mingw64-libssh2-1.8.0-3.fc27.noarch
mingw64-libtasn1-4.13-1.fc27.noarch
mingw64-nettle-3.3-3.fc27.noarch
mingw64-pixman-0.34.0-3.fc27.noarch
mingw64-pkg-config-0.28-9.fc27.x86_64
nettle-devel-3.4-1.fc27.x86_64
perl-5.26.1-402.fc27.x86_64
pixman-devel-0.34.0-4.fc27.x86_64
python3-3.6.2-13.fc27.x86_64
sparse-0.5.1-2.fc27.x86_64
tar-1.29-7.fc27.x86_64
which-2.21-4.fc27.x86_64
zlib-devel-1.2.11-4.fc27.x86_64
Environment variables:
TARGET_LIST=
PACKAGES=ccache gettext git tar PyYAML sparse flex bison python3 bzip2 hostname glib2-devel pixman-devel zlib-devel SDL-devel libfdt-devel gcc gcc-c++ clang make perl which bc findutils libaio-devel nettle-devel libasan libubsan mingw32-pixman mingw32-glib2 mingw32-gmp mingw32-SDL mingw32-pkg-config mingw32-gtk2 mingw32-gtk3 mingw32-gnutls mingw32-nettle mingw32-libtasn1 mingw32-libjpeg-turbo mingw32-libpng mingw32-curl mingw32-libssh2 mingw32-bzip2 mingw64-pixman mingw64-glib2 mingw64-gmp mingw64-SDL mingw64-pkg-config mingw64-gtk2 mingw64-gtk3 mingw64-gnutls mingw64-nettle mingw64-libtasn1 mingw64-libjpeg-turbo mingw64-libpng mingw64-curl mingw64-libssh2 mingw64-bzip2
J=8
V=
HOSTNAME=9b08624a130c
DEBUG=
SHOW_ENV=1
PWD=/
HOME=/root
CCACHE_DIR=/var/tmp/ccache
DISTTAG=f27container
QEMU_CONFIGURE_OPTS=--python=/usr/bin/python3
FGC=f27
TEST_DIR=/tmp/qemu-test
SHLVL=1
FEATURES=mingw clang pyyaml asan dtc
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAKEFLAGS= -j8
EXTRA_CONFIGURE_OPTS=
_=/usr/bin/env
Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu --prefix=/tmp/qemu-test/install --python=/usr/bin/python3 --cross-prefix=x86_64-w64-mingw32- --enable-trace-backends=simple --enable-gnutls --enable-nettle --enable-curl --enable-vnc --enable-bzip2 --enable-guest-agent --with-sdlabi=1.2 --with-gtkabi=2.0
Install prefix /tmp/qemu-test/install
BIOS directory /tmp/qemu-test/install
firmware path /tmp/qemu-test/install/share/qemu-firmware
binary directory /tmp/qemu-test/install
library directory /tmp/qemu-test/install/lib
module directory /tmp/qemu-test/install/lib
libexec directory /tmp/qemu-test/install/libexec
include directory /tmp/qemu-test/install/include
config directory /tmp/qemu-test/install
local state directory queried at runtime
Windows SDK no
Source path /tmp/qemu-test/src
GIT binary git
GIT submodules
C compiler x86_64-w64-mingw32-gcc
Host C compiler cc
C++ compiler x86_64-w64-mingw32-g++
Objective-C compiler clang
ARFLAGS rv
CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt -Werror -DHAS_LIBSSH2_SFTP_FSYNC -mms-bitfields -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/glib-2.0 -I/usr/x86_64-w64-mingw32/sys-root/mingw/lib/glib-2.0/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -m64 -mcx16 -mthreads -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/p11-kit-1 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/libpng16
LDFLAGS -Wl,--nxcompat -Wl,--no-seh -Wl,--dynamicbase -Wl,--warn-common -m64 -g
make make
install install
python /usr/bin/python3 -B
smbd /usr/sbin/smbd
module support no
host CPU x86_64
host big endian no
target list x86_64-softmmu aarch64-softmmu
gprof enabled no
sparse enabled no
strip binaries yes
profiler no
static build no
SDL support yes (1.2.15)
GTK support yes (2.24.31)
GTK GL support no
VTE support no
TLS priority NORMAL
GNUTLS support yes
GNUTLS rnd yes
libgcrypt no
libgcrypt kdf no
nettle yes (3.3)
nettle kdf yes
libtasn1 yes
curses support no
virgl support no
curl support yes
mingw32 support yes
Audio drivers dsound
Block whitelist (rw)
Block whitelist (ro)
VirtFS support no
Multipath support no
VNC support yes
VNC SASL support no
VNC JPEG support yes
VNC PNG support yes
xen support no
brlapi support no
bluez support no
Documentation no
PIE no
vde support no
netmap support no
Linux AIO support no
ATTR/XATTR support no
Install blobs yes
KVM support no
HAX support yes
HVF support no
WHPX support no
TCG support yes
TCG debug enabled no
TCG interpreter no
malloc trim support no
RDMA support no
fdt support yes
preadv support no
fdatasync no
madvise no
posix_madvise no
libcap-ng support no
vhost-net support no
vhost-scsi support no
vhost-vsock support no
vhost-user support no
Trace backends simple
Trace output file trace-<pid>
spice support no
rbd support no
xfsctl support no
smartcard support no
libusb no
usb net redir no
OpenGL support no
OpenGL dmabufs no
libiscsi support no
libnfs support no
build guest agent yes
QGA VSS support no
QGA w32 disk info yes
QGA MSI support no
seccomp support no
coroutine backend win32
coroutine pool yes
debug stack usage no
crypto afalg no
GlusterFS support no
gcov gcov
gcov enabled no
TPM support yes
libssh2 support yes
TPM passthrough no
TPM emulator no
QOM debugging yes
Live block migration yes
lzo support no
snappy support no
bzip2 support yes
NUMA host support no
libxml2 no
tcmalloc support no
jemalloc support no
avx2 optimization yes
replication support yes
VxHS block device no
capstone no
WARNING: Use of GTK 2.0 is deprecated and will be removed in
WARNING: future releases. Please switch to using GTK 3.0
WARNING: Use of SDL 1.2 is deprecated and will be removed in
WARNING: future releases. Please switch to using SDL 2.0
GEN x86_64-softmmu/config-devices.mak.tmp
GEN aarch64-softmmu/config-devices.mak.tmp
GEN config-host.h
GEN qemu-options.def
GEN qmp-commands.h
GEN qapi-types.h
GEN qapi-visit.h
GEN qapi-event.h
GEN x86_64-softmmu/config-devices.mak
GEN aarch64-softmmu/config-devices.mak
GEN qmp-marshal.c
GEN qapi-types.c
GEN qapi-visit.c
GEN qapi-event.c
GEN qmp-introspect.h
GEN qmp-introspect.c
GEN trace/generated-tcg-tracers.h
GEN trace/generated-helpers-wrappers.h
GEN trace/generated-helpers.h
GEN trace/generated-helpers.c
GEN module_block.h
GEN ui/input-keymap-atset1-to-qcode.c
GEN ui/input-keymap-linux-to-qcode.c
GEN ui/input-keymap-qcode-to-atset1.c
GEN ui/input-keymap-qcode-to-atset2.c
GEN ui/input-keymap-qcode-to-atset3.c
GEN ui/input-keymap-qcode-to-linux.c
GEN ui/input-keymap-qcode-to-qnum.c
GEN ui/input-keymap-qcode-to-sun.c
GEN ui/input-keymap-qnum-to-qcode.c
GEN ui/input-keymap-usb-to-qcode.c
GEN ui/input-keymap-win32-to-qcode.c
GEN ui/input-keymap-x11-to-qcode.c
GEN ui/input-keymap-xorgevdev-to-qcode.c
GEN ui/input-keymap-xorgkbd-to-qcode.c
GEN ui/input-keymap-xorgxquartz-to-qcode.c
GEN ui/input-keymap-xorgxwin-to-qcode.c
GEN tests/test-qapi-types.h
GEN tests/test-qapi-visit.h
GEN tests/test-qmp-commands.h
GEN tests/test-qapi-event.h
GEN tests/test-qmp-introspect.h
GEN trace-root.h
GEN util/trace.h
GEN crypto/trace.h
GEN io/trace.h
GEN migration/trace.h
GEN block/trace.h
GEN chardev/trace.h
GEN hw/block/trace.h
GEN hw/block/dataplane/trace.h
GEN hw/char/trace.h
GEN hw/intc/trace.h
GEN hw/net/trace.h
GEN hw/virtio/trace.h
GEN hw/audio/trace.h
GEN hw/misc/trace.h
GEN hw/usb/trace.h
GEN hw/scsi/trace.h
GEN hw/nvram/trace.h
GEN hw/display/trace.h
GEN hw/input/trace.h
GEN hw/timer/trace.h
GEN hw/dma/trace.h
GEN hw/sparc/trace.h
GEN hw/sparc64/trace.h
GEN hw/sd/trace.h
GEN hw/isa/trace.h
GEN hw/mem/trace.h
GEN hw/i386/trace.h
GEN hw/i386/xen/trace.h
GEN hw/9pfs/trace.h
GEN hw/ppc/trace.h
GEN hw/pci/trace.h
GEN hw/pci-host/trace.h
GEN hw/s390x/trace.h
GEN hw/vfio/trace.h
GEN hw/acpi/trace.h
GEN hw/arm/trace.h
GEN hw/alpha/trace.h
GEN hw/hppa/trace.h
GEN hw/xen/trace.h
GEN hw/ide/trace.h
GEN ui/trace.h
GEN audio/trace.h
GEN net/trace.h
GEN target/arm/trace.h
GEN target/i386/trace.h
GEN target/mips/trace.h
GEN target/sparc/trace.h
GEN target/s390x/trace.h
GEN target/ppc/trace.h
GEN qom/trace.h
GEN linux-user/trace.h
GEN qapi/trace.h
GEN accel/tcg/trace.h
GEN accel/kvm/trace.h
GEN nbd/trace.h
GEN scsi/trace.h
GEN trace-root.c
GEN util/trace.c
GEN crypto/trace.c
GEN io/trace.c
GEN migration/trace.c
GEN block/trace.c
GEN chardev/trace.c
GEN hw/block/trace.c
GEN hw/block/dataplane/trace.c
GEN hw/char/trace.c
GEN hw/intc/trace.c
GEN hw/net/trace.c
GEN hw/virtio/trace.c
GEN hw/audio/trace.c
GEN hw/misc/trace.c
GEN hw/usb/trace.c
GEN hw/scsi/trace.c
GEN hw/nvram/trace.c
GEN hw/display/trace.c
GEN hw/input/trace.c
GEN hw/timer/trace.c
GEN hw/dma/trace.c
GEN hw/sparc/trace.c
GEN hw/sparc64/trace.c
GEN hw/sd/trace.c
GEN hw/isa/trace.c
GEN hw/mem/trace.c
GEN hw/i386/trace.c
GEN hw/i386/xen/trace.c
GEN hw/9pfs/trace.c
GEN hw/ppc/trace.c
GEN hw/pci/trace.c
GEN hw/pci-host/trace.c
GEN hw/s390x/trace.c
GEN hw/vfio/trace.c
GEN hw/acpi/trace.c
GEN hw/arm/trace.c
GEN hw/alpha/trace.c
GEN hw/hppa/trace.c
GEN hw/xen/trace.c
GEN hw/ide/trace.c
GEN ui/trace.c
GEN audio/trace.c
GEN net/trace.c
GEN target/arm/trace.c
GEN target/i386/trace.c
GEN target/mips/trace.c
GEN target/sparc/trace.c
GEN target/s390x/trace.c
GEN target/ppc/trace.c
GEN qom/trace.c
GEN linux-user/trace.c
GEN qapi/trace.c
GEN accel/tcg/trace.c
GEN accel/kvm/trace.c
GEN nbd/trace.c
GEN scsi/trace.c
GEN config-all-devices.mak
DEP /tmp/qemu-test/src/dtc/tests/dumptrees.c
DEP /tmp/qemu-test/src/dtc/tests/trees.S
DEP /tmp/qemu-test/src/dtc/tests/value-labels.c
DEP /tmp/qemu-test/src/dtc/tests/testutils.c
DEP /tmp/qemu-test/src/dtc/tests/asm_tree_dump.c
DEP /tmp/qemu-test/src/dtc/tests/truncated_property.c
DEP /tmp/qemu-test/src/dtc/tests/check_path.c
DEP /tmp/qemu-test/src/dtc/tests/overlay_bad_fixup.c
DEP /tmp/qemu-test/src/dtc/tests/overlay.c
DEP /tmp/qemu-test/src/dtc/tests/subnode_iterate.c
DEP /tmp/qemu-test/src/dtc/tests/property_iterate.c
DEP /tmp/qemu-test/src/dtc/tests/integer-expressions.c
DEP /tmp/qemu-test/src/dtc/tests/utilfdt_test.c
DEP /tmp/qemu-test/src/dtc/tests/path_offset_aliases.c
DEP /tmp/qemu-test/src/dtc/tests/add_subnode_with_nops.c
DEP /tmp/qemu-test/src/dtc/tests/dtbs_equal_unordered.c
DEP /tmp/qemu-test/src/dtc/tests/dtb_reverse.c
DEP /tmp/qemu-test/src/dtc/tests/dtbs_equal_ordered.c
DEP /tmp/qemu-test/src/dtc/tests/extra-terminating-null.c
DEP /tmp/qemu-test/src/dtc/tests/incbin.c
DEP /tmp/qemu-test/src/dtc/tests/boot-cpuid.c
DEP /tmp/qemu-test/src/dtc/tests/phandle_format.c
DEP /tmp/qemu-test/src/dtc/tests/path-references.c
DEP /tmp/qemu-test/src/dtc/tests/references.c
DEP /tmp/qemu-test/src/dtc/tests/propname_escapes.c
DEP /tmp/qemu-test/src/dtc/tests/string_escapes.c
DEP /tmp/qemu-test/src/dtc/tests/appendprop2.c
DEP /tmp/qemu-test/src/dtc/tests/appendprop1.c
DEP /tmp/qemu-test/src/dtc/tests/del_node.c
DEP /tmp/qemu-test/src/dtc/tests/setprop.c
DEP /tmp/qemu-test/src/dtc/tests/del_property.c
DEP /tmp/qemu-test/src/dtc/tests/set_name.c
DEP /tmp/qemu-test/src/dtc/tests/rw_tree1.c
DEP /tmp/qemu-test/src/dtc/tests/open_pack.c
DEP /tmp/qemu-test/src/dtc/tests/nopulate.c
DEP /tmp/qemu-test/src/dtc/tests/mangle-layout.c
DEP /tmp/qemu-test/src/dtc/tests/move_and_save.c
DEP /tmp/qemu-test/src/dtc/tests/sw_tree1.c
DEP /tmp/qemu-test/src/dtc/tests/nop_node.c
DEP /tmp/qemu-test/src/dtc/tests/nop_property.c
DEP /tmp/qemu-test/src/dtc/tests/setprop_inplace.c
DEP /tmp/qemu-test/src/dtc/tests/stringlist.c
DEP /tmp/qemu-test/src/dtc/tests/addr_size_cells.c
DEP /tmp/qemu-test/src/dtc/tests/notfound.c
DEP /tmp/qemu-test/src/dtc/tests/sized_cells.c
DEP /tmp/qemu-test/src/dtc/tests/char_literal.c
DEP /tmp/qemu-test/src/dtc/tests/get_alias.c
DEP /tmp/qemu-test/src/dtc/tests/node_offset_by_compatible.c
DEP /tmp/qemu-test/src/dtc/tests/node_check_compatible.c
DEP /tmp/qemu-test/src/dtc/tests/node_offset_by_phandle.c
DEP /tmp/qemu-test/src/dtc/tests/node_offset_by_prop_value.c
DEP /tmp/qemu-test/src/dtc/tests/supernode_atdepth_offset.c
DEP /tmp/qemu-test/src/dtc/tests/get_path.c
DEP /tmp/qemu-test/src/dtc/tests/parent_offset.c
DEP /tmp/qemu-test/src/dtc/tests/getprop.c
DEP /tmp/qemu-test/src/dtc/tests/get_name.c
DEP /tmp/qemu-test/src/dtc/tests/get_phandle.c
DEP /tmp/qemu-test/src/dtc/tests/path_offset.c
DEP /tmp/qemu-test/src/dtc/tests/subnode_offset.c
DEP /tmp/qemu-test/src/dtc/tests/find_property.c
DEP /tmp/qemu-test/src/dtc/tests/root_node.c
DEP /tmp/qemu-test/src/dtc/tests/get_mem_rsv.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_overlay.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_addresses.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_empty_tree.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_strerror.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_rw.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_sw.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_wip.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_ro.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt.c
DEP /tmp/qemu-test/src/dtc/util.c
DEP /tmp/qemu-test/src/dtc/fdtoverlay.c
DEP /tmp/qemu-test/src/dtc/fdtput.c
DEP /tmp/qemu-test/src/dtc/fdtget.c
DEP /tmp/qemu-test/src/dtc/fdtdump.c
LEX convert-dtsv0-lexer.lex.c
DEP /tmp/qemu-test/src/dtc/srcpos.c
BISON dtc-parser.tab.c
LEX dtc-lexer.lex.c
DEP /tmp/qemu-test/src/dtc/treesource.c
DEP /tmp/qemu-test/src/dtc/fstree.c
DEP /tmp/qemu-test/src/dtc/livetree.c
DEP /tmp/qemu-test/src/dtc/flattree.c
DEP /tmp/qemu-test/src/dtc/dtc.c
DEP /tmp/qemu-test/src/dtc/data.c
DEP /tmp/qemu-test/src/dtc/checks.c
DEP convert-dtsv0-lexer.lex.c
DEP dtc-parser.tab.c
DEP dtc-lexer.lex.c
CHK version_gen.h
UPD version_gen.h
DEP /tmp/qemu-test/src/dtc/util.c
CC libfdt/fdt.o
CC libfdt/fdt_ro.o
CC libfdt/fdt_rw.o
CC libfdt/fdt_wip.o
CC libfdt/fdt_sw.o
CC libfdt/fdt_strerror.o
CC libfdt/fdt_empty_tree.o
CC libfdt/fdt_addresses.o
CC libfdt/fdt_overlay.o
AR libfdt/libfdt.a
x86_64-w64-mingw32-ar: creating libfdt/libfdt.a
a - libfdt/fdt.o
a - libfdt/fdt_ro.o
a - libfdt/fdt_wip.o
a - libfdt/fdt_sw.o
a - libfdt/fdt_rw.o
a - libfdt/fdt_strerror.o
a - libfdt/fdt_empty_tree.o
a - libfdt/fdt_addresses.o
a - libfdt/fdt_overlay.o
RC version.o
GEN qga/qapi-generated/qga-qapi-types.h
GEN qga/qapi-generated/qga-qapi-visit.h
GEN qga/qapi-generated/qga-qmp-commands.h
GEN qga/qapi-generated/qga-qapi-visit.c
CC qmp-introspect.o
GEN qga/qapi-generated/qga-qapi-types.c
CC qapi-types.o
GEN qga/qapi-generated/qga-qmp-marshal.c
CC qapi-visit.o
CC qapi-event.o
CC qapi/qapi-visit-core.o
CC qapi/qapi-dealloc-visitor.o
CC qapi/qobject-input-visitor.o
CC qapi/qobject-output-visitor.o
CC qapi/qmp-registry.o
CC qapi/qmp-dispatch.o
CC qapi/string-input-visitor.o
CC qapi/string-output-visitor.o
CC qapi/opts-visitor.o
CC qapi/qapi-clone-visitor.o
CC qapi/qmp-event.o
CC qapi/qapi-util.o
CC qobject/qnull.o
CC qobject/qnum.o
CC qobject/qstring.o
CC qobject/qdict.o
CC qobject/qlist.o
CC qobject/qbool.o
CC qobject/qlit.o
CC qobject/qjson.o
CC qobject/qobject.o
CC qobject/json-lexer.o
CC qobject/json-streamer.o
CC qobject/json-parser.o
CC trace/simple.o
CC trace/control.o
CC trace/qmp.o
CC util/osdep.o
CC util/cutils.o
CC util/qemu-timer-common.o
CC util/unicode.o
CC util/bufferiszero.o
CC util/lockcnt.o
CC util/aiocb.o
CC util/async.o
CC util/thread-pool.o
CC util/qemu-timer.o
CC util/main-loop.o
CC util/iohandler.o
CC util/aio-win32.o
CC util/event_notifier-win32.o
CC util/oslib-win32.o
CC util/qemu-thread-win32.o
CC util/envlist.o
CC util/path.o
CC util/module.o
CC util/host-utils.o
CC util/bitmap.o
CC util/bitops.o
CC util/hbitmap.o
CC util/fifo8.o
CC util/acl.o
CC util/cacheinfo.o
CC util/error.o
CC util/qemu-error.o
CC util/id.o
CC util/iov.o
CC util/qemu-config.o
CC util/qemu-sockets.o
CC util/uri.o
CC util/notify.o
CC util/qemu-option.o
CC util/qemu-progress.o
CC util/keyval.o
CC util/hexdump.o
CC util/crc32c.o
CC util/uuid.o
CC util/throttle.o
CC util/getauxval.o
CC util/readline.o
CC util/rcu.o
CC util/qemu-coroutine.o
CC util/qemu-coroutine-lock.o
CC util/qemu-coroutine-io.o
CC util/qemu-coroutine-sleep.o
CC util/coroutine-win32.o
CC util/buffer.o
CC util/timed-average.o
CC util/base64.o
CC util/log.o
CC util/pagesize.o
CC util/qdist.o
CC util/qht.o
CC util/range.o
CC util/stats64.o
CC util/systemd.o
CC trace-root.o
CC util/trace.o
CC crypto/trace.o
CC io/trace.o
CC migration/trace.o
CC block/trace.o
CC chardev/trace.o
CC hw/block/trace.o
CC hw/block/dataplane/trace.o
CC hw/char/trace.o
CC hw/intc/trace.o
CC hw/net/trace.o
CC hw/virtio/trace.o
CC hw/audio/trace.o
CC hw/misc/trace.o
CC hw/usb/trace.o
CC hw/scsi/trace.o
CC hw/nvram/trace.o
CC hw/display/trace.o
CC hw/input/trace.o
CC hw/timer/trace.o
CC hw/dma/trace.o
CC hw/sparc/trace.o
CC hw/sparc64/trace.o
CC hw/sd/trace.o
CC hw/isa/trace.o
CC hw/mem/trace.o
CC hw/i386/trace.o
CC hw/i386/xen/trace.o
CC hw/9pfs/trace.o
CC hw/ppc/trace.o
CC hw/pci/trace.o
CC hw/pci-host/trace.o
CC hw/s390x/trace.o
CC hw/vfio/trace.o
CC hw/acpi/trace.o
CC hw/arm/trace.o
CC hw/alpha/trace.o
CC hw/hppa/trace.o
CC hw/xen/trace.o
CC hw/ide/trace.o
CC ui/trace.o
CC audio/trace.o
CC net/trace.o
CC target/arm/trace.o
CC target/i386/trace.o
CC target/mips/trace.o
CC target/sparc/trace.o
CC target/s390x/trace.o
CC target/ppc/trace.o
CC qom/trace.o
CC linux-user/trace.o
CC qapi/trace.o
CC accel/tcg/trace.o
CC accel/kvm/trace.o
CC nbd/trace.o
CC scsi/trace.o
CC crypto/pbkdf-stub.o
CC stubs/arch-query-cpu-def.o
CC stubs/arch-query-cpu-model-expansion.o
CC stubs/arch-query-cpu-model-comparison.o
CC stubs/arch-query-cpu-model-baseline.o
CC stubs/bdrv-next-monitor-owned.o
CC stubs/blk-commit-all.o
CC stubs/blockdev-close-all-bdrv-states.o
CC stubs/cpu-get-clock.o
CC stubs/clock-warp.o
CC stubs/cpu-get-icount.o
CC stubs/dump.o
CC stubs/error-printf.o
CC stubs/fdset.o
CC stubs/gdbstub.o
CC stubs/get-vm-name.o
CC stubs/iothread.o
CC stubs/iothread-lock.o
CC stubs/is-daemonized.o
CC stubs/machine-init-done.o
CC stubs/migr-blocker.o
CC stubs/change-state-handler.o
CC stubs/monitor.o
CC stubs/notify-event.o
CC stubs/qtest.o
CC stubs/replay.o
CC stubs/runstate-check.o
CC stubs/set-fd-handler.o
CC stubs/slirp.o
CC stubs/sysbus.o
CC stubs/tpm.o
CC stubs/trace-control.o
CC stubs/uuid.o
CC stubs/vm-stop.o
CC stubs/vmstate.o
CC stubs/fd-register.o
CC stubs/qmp_pc_dimm.o
CC stubs/target-monitor-defs.o
CC stubs/target-get-monitor-def.o
CC stubs/pc_madt_cpu_entry.o
CC stubs/vmgenid.o
CC stubs/xen-common.o
CC stubs/xen-hvm.o
CC stubs/pci-host-piix.o
CC stubs/ram-block.o
GEN qemu-img-cmds.h
CC block.o
CC blockjob.o
CC replication.o
CC qemu-io-cmds.o
CC block/raw-format.o
CC block/qcow.o
CC block/vdi.o
CC block/vmdk.o
CC block/cloop.o
CC block/bochs.o
CC block/vpc.o
CC block/vvfat.o
CC block/dmg.o
CC block/qcow2.o
CC block/qcow2-refcount.o
CC block/qcow2-cluster.o
CC block/qcow2-snapshot.o
CC block/qcow2-cache.o
CC block/qcow2-bitmap.o
CC block/qed.o
CC block/qed-l2-cache.o
CC block/qed-table.o
CC block/qed-cluster.o
CC block/qed-check.o
CC block/vhdx.o
CC block/vhdx-endian.o
CC block/vhdx-log.o
CC block/quorum.o
CC block/parallels.o
CC block/blkdebug.o
CC block/blkverify.o
CC block/blkreplay.o
CC block/block-backend.o
CC block/snapshot.o
CC block/qapi.o
CC block/file-win32.o
CC block/win32-aio.o
CC block/null.o
CC block/mirror.o
CC block/commit.o
CC block/io.o
CC block/throttle-groups.o
CC block/nbd.o
CC block/nbd-client.o
CC block/sheepdog.o
CC block/accounting.o
CC block/dirty-bitmap.o
CC block/write-threshold.o
CC block/backup.o
CC block/replication.o
CC block/throttle.o
CC block/crypto.o
CC nbd/server.o
CC nbd/client.o
CC nbd/common.o
CC scsi/utils.o
CC block/curl.o
CC block/ssh.o
CC crypto/init.o
CC block/dmg-bz2.o
CC crypto/hash.o
CC crypto/hash-nettle.o
CC crypto/hmac.o
CC crypto/hmac-nettle.o
CC crypto/desrfb.o
CC crypto/aes.o
CC crypto/cipher.o
CC crypto/tlscreds.o
CC crypto/tlscredsanon.o
CC crypto/tlscredsx509.o
CC crypto/tlssession.o
CC crypto/secret.o
CC crypto/random-gnutls.o
CC crypto/pbkdf-nettle.o
CC crypto/pbkdf.o
CC crypto/ivgen.o
CC crypto/ivgen-essiv.o
CC crypto/ivgen-plain.o
CC crypto/ivgen-plain64.o
CC crypto/afsplit.o
CC crypto/xts.o
CC crypto/block.o
CC crypto/block-qcow.o
CC crypto/block-luks.o
CC io/channel.o
CC io/channel-buffer.o
CC io/channel-command.o
CC io/channel-file.o
CC io/channel-socket.o
CC io/channel-tls.o
CC io/channel-watch.o
CC io/channel-websock.o
CC io/channel-util.o
CC io/dns-resolver.o
CC io/net-listener.o
CC io/task.o
CC qom/object.o
CC qom/container.o
CC qom/qom-qobject.o
CC qom/object_interfaces.o
CC qemu-io.o
CC blockdev.o
CC blockdev-nbd.o
CC bootdevice.o
CC iothread.o
CC qdev-monitor.o
CC device-hotplug.o
CC os-win32.o
CC bt-host.o
CC bt-vhci.o
CC dma-helpers.o
CC vl.o
CC tpm.o
CC device_tree.o
CC qmp.o
CC qmp-marshal.o
CC hmp.o
CC cpus-common.o
CC audio/audio.o
CC audio/noaudio.o
CC audio/wavaudio.o
CC audio/mixeng.o
CC audio/sdlaudio.o
CC audio/dsoundaudio.o
CC audio/audio_win_int.o
CC audio/wavcapture.o
CC backends/rng.o
CC backends/rng-egd.o
CC backends/tpm.o
CC backends/hostmem.o
CC backends/hostmem-ram.o
CC backends/cryptodev.o
CC backends/cryptodev-builtin.o
CC block/stream.o
CC chardev/msmouse.o
CC chardev/wctablet.o
CC chardev/testdev.o
CC disas/arm.o
CXX disas/arm-a64.o
CC disas/i386.o
CXX disas/libvixl/vixl/utils.o
CXX disas/libvixl/vixl/compiler-intrinsics.o
CXX disas/libvixl/vixl/a64/instructions-a64.o
CXX disas/libvixl/vixl/a64/decoder-a64.o
CXX disas/libvixl/vixl/a64/disasm-a64.o
CC hw/acpi/core.o
CC hw/acpi/piix4.o
CC hw/acpi/pcihp.o
CC hw/acpi/ich9.o
CC hw/acpi/tco.o
CC hw/acpi/cpu_hotplug.o
CC hw/acpi/memory_hotplug.o
CC hw/acpi/cpu.o
CC hw/acpi/nvdimm.o
CC hw/acpi/vmgenid.o
CC hw/acpi/acpi_interface.o
CC hw/acpi/bios-linker-loader.o
CC hw/acpi/aml-build.o
CC hw/acpi/ipmi.o
CC hw/acpi/acpi-stub.o
CC hw/acpi/ipmi-stub.o
CC hw/audio/sb16.o
CC hw/audio/es1370.o
CC hw/audio/ac97.o
CC hw/audio/fmopl.o
CC hw/audio/adlib.o
CC hw/audio/gus.o
CC hw/audio/gusemu_hal.o
CC hw/audio/gusemu_mixer.o
CC hw/audio/cs4231a.o
CC hw/audio/intel-hda.o
CC hw/audio/hda-codec.o
CC hw/audio/pcspk.o
CC hw/audio/pl041.o
CC hw/audio/wm8750.o
CC hw/audio/lm4549.o
CC hw/audio/marvell_88w8618.o
CC hw/audio/soundhw.o
CC hw/block/block.o
CC hw/block/hd-geometry.o
CC hw/block/cdrom.o
CC hw/block/fdc.o
CC hw/block/m25p80.o
CC hw/block/nand.o
CC hw/block/pflash_cfi01.o
CC hw/block/pflash_cfi02.o
CC hw/block/ecc.o
CC hw/block/onenand.o
CC hw/block/nvme.o
CC hw/bt/core.o
CC hw/bt/l2cap.o
CC hw/bt/sdp.o
CC hw/bt/hci.o
CC hw/bt/hid.o
CC hw/bt/hci-csr.o
CC hw/char/ipoctal232.o
CC hw/char/parallel.o
CC hw/char/pl011.o
CC hw/char/serial.o
CC hw/char/serial-isa.o
CC hw/char/serial-pci.o
CC hw/char/virtio-console.o
CC hw/char/cadence_uart.o
CC hw/char/cmsdk-apb-uart.o
CC hw/char/debugcon.o
CC hw/char/imx_serial.o
CC hw/core/qdev.o
CC hw/core/qdev-properties.o
CC hw/core/bus.o
CC hw/core/reset.o
CC hw/core/qdev-fw.o
CC hw/core/fw-path-provider.o
CC hw/core/irq.o
CC hw/core/hotplug.o
CC hw/core/nmi.o
CC hw/core/stream.o
CC hw/core/ptimer.o
CC hw/core/sysbus.o
CC hw/core/machine.o
CC hw/core/loader.o
CC hw/core/qdev-properties-system.o
CC hw/core/register.o
CC hw/core/or-irq.o
CC hw/core/platform-bus.o
CC hw/cpu/core.o
CC hw/display/ads7846.o
CC hw/display/cirrus_vga.o
CC hw/display/pl110.o
CC hw/display/ssd0303.o
CC hw/display/ssd0323.o
CC hw/display/vga-pci.o
CC hw/display/vga-isa.o
CC hw/display/vmware_vga.o
CC hw/display/blizzard.o
CC hw/display/exynos4210_fimd.o
CC hw/display/tc6393xb.o
CC hw/display/framebuffer.o
CC hw/dma/pl080.o
CC hw/dma/pl330.o
CC hw/dma/i8257.o
CC hw/dma/xilinx_axidma.o
CC hw/dma/xlnx-zynq-devcfg.o
CC hw/gpio/max7310.o
CC hw/gpio/zaurus.o
CC hw/gpio/pl061.o
CC hw/gpio/gpio_key.o
CC hw/i2c/core.o
CC hw/i2c/smbus.o
CC hw/i2c/smbus_eeprom.o
CC hw/i2c/i2c-ddc.o
CC hw/i2c/versatile_i2c.o
CC hw/i2c/smbus_ich9.o
CC hw/i2c/pm_smbus.o
CC hw/i2c/bitbang_i2c.o
CC hw/i2c/exynos4210_i2c.o
CC hw/i2c/imx_i2c.o
CC hw/i2c/aspeed_i2c.o
CC hw/ide/core.o
CC hw/ide/atapi.o
CC hw/ide/qdev.o
CC hw/ide/pci.o
CC hw/ide/isa.o
CC hw/ide/piix.o
CC hw/ide/microdrive.o
CC hw/ide/ahci.o
CC hw/ide/ich.o
CC hw/ide/ahci-allwinner.o
CC hw/input/hid.o
CC hw/input/lm832x.o
CC hw/input/pckbd.o
CC hw/input/pl050.o
CC hw/input/ps2.o
CC hw/input/stellaris_input.o
CC hw/input/tsc2005.o
CC hw/input/virtio-input.o
CC hw/input/virtio-input-hid.o
CC hw/intc/i8259_common.o
CC hw/intc/i8259.o
CC hw/intc/pl190.o
CC hw/intc/xlnx-pmu-iomod-intc.o
CC hw/intc/xlnx-zynqmp-ipi.o
CC hw/intc/imx_avic.o
CC hw/intc/realview_gic.o
CC hw/intc/ioapic_common.o
CC hw/intc/arm_gic_common.o
CC hw/intc/arm_gic.o
CC hw/intc/arm_gicv2m.o
CC hw/intc/arm_gicv3_common.o
CC hw/intc/arm_gicv3.o
CC hw/intc/arm_gicv3_dist.o
CC hw/intc/arm_gicv3_redist.o
CC hw/intc/arm_gicv3_its_common.o
CC hw/intc/intc.o
CC hw/ipack/ipack.o
CC hw/ipack/tpci200.o
CC hw/ipmi/ipmi.o
CC hw/ipmi/ipmi_bmc_sim.o
CC hw/ipmi/ipmi_bmc_extern.o
CC hw/ipmi/isa_ipmi_kcs.o
CC hw/ipmi/isa_ipmi_bt.o
CC hw/isa/isa-bus.o
CC hw/isa/apm.o
CC hw/mem/pc-dimm.o
CC hw/mem/nvdimm.o
CC hw/misc/applesmc.o
CC hw/misc/max111x.o
CC hw/misc/tmp105.o
CC hw/misc/tmp421.o
CC hw/misc/debugexit.o
CC hw/misc/sga.o
CC hw/misc/pc-testdev.o
CC hw/misc/pci-testdev.o
CC hw/misc/edu.o
CC hw/misc/unimp.o
CC hw/misc/vmcoreinfo.o
In file included from /tmp/qemu-test/src/hw/input/virtio-input.c:16:0:
/tmp/qemu-test/src/include/standard-headers/linux/input.h:26:6: error: "__BITS_PER_LONG" is not defined, evaluates to 0 [-Werror=undef]
#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL)
^~~~~~~~~~~~~~~
CC hw/misc/arm_l2x0.o
CC hw/misc/arm_integrator_debug.o
CC hw/misc/a9scu.o
CC hw/misc/arm11scu.o
CC hw/net/ne2000.o
CC hw/net/eepro100.o
CC hw/net/pcnet-pci.o
In file included from /tmp/qemu-test/src/hw/input/virtio-input-hid.c:17:0:
/tmp/qemu-test/src/include/standard-headers/linux/input.h:26:6: error: "__BITS_PER_LONG" is not defined, evaluates to 0 [-Werror=undef]
#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL)
^~~~~~~~~~~~~~~
CC hw/net/pcnet.o
CC hw/net/e1000.o
CC hw/net/e1000x_common.o
CC hw/net/net_tx_pkt.o
cc1: all warnings being treated as errors
make: *** [/tmp/qemu-test/src/rules.mak:66: hw/input/virtio-input-hid.o] Error 1
make: *** Waiting for unfinished jobs....
cc1: all warnings being treated as errors
make: *** [/tmp/qemu-test/src/rules.mak:66: hw/input/virtio-input.o] Error 1
Traceback (most recent call last):
File "./tests/docker/docker.py", line 407, in <module>
sys.exit(main())
File "./tests/docker/docker.py", line 404, in main
return args.cmdobj.run(args, argv)
File "./tests/docker/docker.py", line 261, in run
return Docker().run(argv, args.keep, quiet=args.quiet)
File "./tests/docker/docker.py", line 229, in run
quiet=quiet)
File "./tests/docker/docker.py", line 147, in _do_check
return subprocess.check_call(self._command + cmd, **kwargs)
File "/usr/lib64/python2.7/subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['docker', 'run', '--label', 'com.qemu.instance.uuid=d0f274ac0d6f11e8b16d52540069c830', '-u', '0', '--security-opt', 'seccomp=unconfined', '--rm', '--net=none', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=8', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/root/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-xq_0lpqh/src/docker-src.2018-02-09-03.04.00.26226:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit status 2
make[1]: *** [tests/docker/Makefile.include:129: docker-run] Error 1
make: *** [tests/docker/Makefile.include:163: docker-run-test-mingw@fedora] Error 2
real 1m28.640s
user 0m4.493s
sys 0m3.253s
=== OUTPUT END ===
Test command exited with code: 2
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 1/4] linux-headers: update to f1517df8701c
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 1/4] linux-headers: update to f1517df8701c Alexey Kardashevskiy
@ 2018-02-10 7:34 ` David Gibson
0 siblings, 0 replies; 34+ messages in thread
From: David Gibson @ 2018-02-10 7:34 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: qemu-devel, qemu-ppc, Alex Williamson
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
On Fri, Feb 09, 2018 at 06:55:00PM +1100, Alexey Kardashevskiy wrote:
> Update headers against f1517df8701c.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f1517df8701c
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Might be worth mentioning that a32295c612c57 is the specific kernel
commit you want to include here, but in any case
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions Alexey Kardashevskiy
@ 2018-02-12 5:19 ` David Gibson
2018-02-12 7:05 ` Alexey Kardashevskiy
2018-03-19 20:49 ` Auger Eric
1 sibling, 1 reply; 34+ messages in thread
From: David Gibson @ 2018-02-12 5:19 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: qemu-devel, qemu-ppc, Alex Williamson
[-- Attachment #1: Type: text/plain, Size: 7197 bytes --]
On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
> At the moment if vfio_memory_listener is registered in the system memory
> address space, it maps/unmaps every RAM memory region for DMA.
> It expects system page size aligned memory sections so vfio_dma_map
> would not fail and so far this has been the case. A mapping failure
> would be fatal. A side effect of such behavior is that some MMIO pages
> would not be mapped silently.
>
> However we are going to change MSIX BAR handling so we will end having
> non-aligned sections in vfio_memory_listener (more details is in
> the next patch) and vfio_dma_map will exit QEMU.
>
> In order to avoid fatal failures on what previously was not a failure and
> was just silently ignored, this checks the section alignment to
> the smallest supported IOMMU page size and prints an error if not aligned;
> it also prints an error if vfio_dma_map failed despite the page size check.
> Both errors are not fatal; only MMIO RAM regions are checked
> (aka "RAM device" regions).
>
> If the amount of errors printed is overwhelming, the MSIX relocation
> could be used to avoid excessive error output.
>
> This is unlikely to cause any behavioral change.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
There are some relatively superficial problems noted below.
But more fundamentally, this feels like it's extending an existing
hack past the point of usefulness.
The explicit check for is_ram_device() here has always bothered me -
it's not like a real bus bridge magically knows whether a target
address maps to RAM or not.
What I think is really going on is that even for systems without an
IOMMU, it's not really true to say that the PCI address space maps
directly onto address_space_memory. Instead, there's a large, but
much less than 2^64 sized, "upstream window" at address 0 on the PCI
bus, which is identity mapped to the system bus. Details will vary
with the system, but in practice we expect nothing but RAM to be in
that window. Addresses not within that window won't be mapped to the
system bus but will just be broadcast on the PCI bus and might be
picked up as a p2p transaction. Actually on classic PC, I suspect
there may be two windows, below and above the "ISA IO hole".
With PCIe it gets more complicated, of course. I still suspect
there's some sort of upstream window to the host, but whether things
outside the window get reflected back down the PCIe heirarchy will
depend on those p2p relevant configuration parameters.
Maybe it's time we had a detailed look at what really happens in
physical bridges, rather than faking it with the is_ram_device()
check?
Anyway, that said, the patch below might still be a reasonable interim
hack, once the smaller problems are fixed.
> ---
> hw/vfio/common.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index f895e3c..736f271 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -544,18 +544,40 @@ static void vfio_listener_region_add(MemoryListener *listener,
>
> llsize = int128_sub(llend, int128_make64(iova));
>
> + if (memory_region_is_ram_device(section->mr)) {
> + hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
> +
> + if ((iova & pgmask) || (llsize & pgmask)) {
> + error_report("Region 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx
> + " is not aligned to 0x%"HWADDR_PRIx
> + " and cannot be mapped for DMA",
> + section->offset_within_region,
> + int128_getlo(section->size),
> + pgmask + 1);
> + return;
> + }
> + }
> +
> ret = vfio_dma_map(container, iova, int128_get64(llsize),
> vaddr, section->readonly);
> if (ret) {
> error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
> "0x%"HWADDR_PRIx", %p) = %d (%m)",
> container, iova, int128_get64(llsize), vaddr, ret);
> + if (memory_region_is_ram_device(section->mr)) {
> + /* Allow unexpected mappings not to be fatal for RAM devices */
> + return;
> + }
> goto fail;
> }
>
> return;
>
> fail:
> + if (memory_region_is_ram_device(section->mr)) {
> + error_report("failed to vfio_dma_map. pci p2p may not work");
Isn't this logic exactly backwards? p2p will be affected when a *non
RAM* device (itself probably a PCI MMIO window) can't be mapped in.
> + return;
> + }
> /*
> * On the initfn path, store the first error in the container so we
> * can gracefully fail. Runtime, there's not much we can do other
> @@ -577,6 +599,7 @@ static void vfio_listener_region_del(MemoryListener *listener,
> hwaddr iova, end;
> Int128 llend, llsize;
> int ret;
> + bool try_unmap = true;
>
> if (vfio_listener_skipped_section(section)) {
> trace_vfio_listener_region_del_skip(
> @@ -629,13 +652,33 @@ static void vfio_listener_region_del(MemoryListener *listener,
>
> trace_vfio_listener_region_del(iova, end);
>
> - ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
> + if (memory_region_is_ram_device(section->mr)) {
> + hwaddr pgmask;
> + VFIOHostDMAWindow *hostwin;
> + bool hostwin_found = false;
> +
> + QLIST_FOREACH(hostwin, &container->hostwin_list, hostwin_next) {
> + if (hostwin->min_iova <= iova && end <= hostwin->max_iova) {
> + hostwin_found = true;
> + break;
> + }
> + }
> + assert(hostwin_found); /* or region_add() would have failed */
> +
> + pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
> + try_unmap = !((iova & pgmask) || (llsize & pgmask));
Explicit page mask checks seem bogus here. We should unmap based on
whether we mapped, not on some other criterion which may or may not
evaluate to the same thing.
> + }
> +
> + if (try_unmap) {
> + ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
> + if (ret) {
> + error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
> + "0x%"HWADDR_PRIx") = %d (%m)",
> + container, iova, int128_get64(llsize), ret);
> + }
> + }
> +
> memory_region_unref(section->mr);
> - if (ret) {
> - error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
> - "0x%"HWADDR_PRIx") = %d (%m)",
> - container, iova, int128_get64(llsize), ret);
> - }
>
> if (container->iommu_type == VFIO_SPAPR_TCE_v2_IOMMU) {
> vfio_spapr_remove_window(container,
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-12 5:19 ` David Gibson
@ 2018-02-12 7:05 ` Alexey Kardashevskiy
2018-02-12 16:06 ` Alex Williamson
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-12 7:05 UTC (permalink / raw)
To: David Gibson; +Cc: qemu-devel, qemu-ppc, Alex Williamson
[-- Attachment #1: Type: text/plain, Size: 7730 bytes --]
On 12/02/18 16:19, David Gibson wrote:
> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>> At the moment if vfio_memory_listener is registered in the system memory
>> address space, it maps/unmaps every RAM memory region for DMA.
>> It expects system page size aligned memory sections so vfio_dma_map
>> would not fail and so far this has been the case. A mapping failure
>> would be fatal. A side effect of such behavior is that some MMIO pages
>> would not be mapped silently.
>>
>> However we are going to change MSIX BAR handling so we will end having
>> non-aligned sections in vfio_memory_listener (more details is in
>> the next patch) and vfio_dma_map will exit QEMU.
>>
>> In order to avoid fatal failures on what previously was not a failure and
>> was just silently ignored, this checks the section alignment to
>> the smallest supported IOMMU page size and prints an error if not aligned;
>> it also prints an error if vfio_dma_map failed despite the page size check.
>> Both errors are not fatal; only MMIO RAM regions are checked
>> (aka "RAM device" regions).
>>
>> If the amount of errors printed is overwhelming, the MSIX relocation
>> could be used to avoid excessive error output.
>>
>> This is unlikely to cause any behavioral change.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> There are some relatively superficial problems noted below.
>
> But more fundamentally, this feels like it's extending an existing
> hack past the point of usefulness.
>
> The explicit check for is_ram_device() here has always bothered me -
> it's not like a real bus bridge magically knows whether a target
> address maps to RAM or not.
>
> What I think is really going on is that even for systems without an
> IOMMU, it's not really true to say that the PCI address space maps
> directly onto address_space_memory. Instead, there's a large, but
> much less than 2^64 sized, "upstream window" at address 0 on the PCI
> bus, which is identity mapped to the system bus. Details will vary
> with the system, but in practice we expect nothing but RAM to be in
> that window. Addresses not within that window won't be mapped to the
> system bus but will just be broadcast on the PCI bus and might be
> picked up as a p2p transaction.
Currently this p2p works only via the IOMMU, direct p2p is not possible as
the guest needs to know physical MMIO addresses to make p2p work and it
does not.
> Actually on classic PC, I suspect
> there may be two windows, below and above the "ISA IO hole".
>
> With PCIe it gets more complicated, of course. I still suspect
> there's some sort of upstream window to the host, but whether things
> outside the window get reflected back down the PCIe heirarchy will
> depend on those p2p relevant configuration parameters.
>
> Maybe it's time we had a detailed look at what really happens in
> physical bridges, rather than faking it with the is_ram_device()
> check?
>
> Anyway, that said, the patch below might still be a reasonable interim
> hack, once the smaller problems are fixed.
>
>> ---
>> hw/vfio/common.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++------
>> 1 file changed, 49 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>> index f895e3c..736f271 100644
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -544,18 +544,40 @@ static void vfio_listener_region_add(MemoryListener *listener,
>>
>> llsize = int128_sub(llend, int128_make64(iova));
>>
>> + if (memory_region_is_ram_device(section->mr)) {
>> + hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
>> +
>> + if ((iova & pgmask) || (llsize & pgmask)) {
>> + error_report("Region 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx
>> + " is not aligned to 0x%"HWADDR_PRIx
>> + " and cannot be mapped for DMA",
>> + section->offset_within_region,
>> + int128_getlo(section->size),
>> + pgmask + 1);
>> + return;
>> + }
>> + }
>> +
>> ret = vfio_dma_map(container, iova, int128_get64(llsize),
>> vaddr, section->readonly);
>> if (ret) {
>> error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
>> "0x%"HWADDR_PRIx", %p) = %d (%m)",
>> container, iova, int128_get64(llsize), vaddr, ret);
>> + if (memory_region_is_ram_device(section->mr)) {
>> + /* Allow unexpected mappings not to be fatal for RAM devices */
>> + return;
>> + }
>> goto fail;
>> }
>>
>> return;
>>
>> fail:
>> + if (memory_region_is_ram_device(section->mr)) {
>> + error_report("failed to vfio_dma_map. pci p2p may not work");
>
> Isn't this logic exactly backwards? p2p will be affected when a *non
> RAM* device (itself probably a PCI MMIO window) can't be mapped in.
"RAM device MR" == "mapped MMIO MR". "Non RAM device" is just the guest
RAM. Everything else (such as IO MRs) is filtered out by
vfio_listener_skipped_section().
>
>> + return;
>> + }
>> /*
>> * On the initfn path, store the first error in the container so we
>> * can gracefully fail. Runtime, there's not much we can do other
>> @@ -577,6 +599,7 @@ static void vfio_listener_region_del(MemoryListener *listener,
>> hwaddr iova, end;
>> Int128 llend, llsize;
>> int ret;
>> + bool try_unmap = true;
>>
>> if (vfio_listener_skipped_section(section)) {
>> trace_vfio_listener_region_del_skip(
>> @@ -629,13 +652,33 @@ static void vfio_listener_region_del(MemoryListener *listener,
>>
>> trace_vfio_listener_region_del(iova, end);
>>
>> - ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
>> + if (memory_region_is_ram_device(section->mr)) {
>> + hwaddr pgmask;
>> + VFIOHostDMAWindow *hostwin;
>> + bool hostwin_found = false;
>> +
>> + QLIST_FOREACH(hostwin, &container->hostwin_list, hostwin_next) {
>> + if (hostwin->min_iova <= iova && end <= hostwin->max_iova) {
>> + hostwin_found = true;
>> + break;
>> + }
>> + }
>> + assert(hostwin_found); /* or region_add() would have failed */
>> +
>> + pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
>> + try_unmap = !((iova & pgmask) || (llsize & pgmask));
>
> Explicit page mask checks seem bogus here. We should unmap based on
> whether we mapped, not on some other criterion which may or may not
> evaluate to the same thing.
There is no mapped sections tracking on the QEMU side, adding it for the
purpose of this patchset looks overkill.
>> + }
>> +
>> + if (try_unmap) {
>> + ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
>> + if (ret) {
>> + error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
>> + "0x%"HWADDR_PRIx") = %d (%m)",
>> + container, iova, int128_get64(llsize), ret);
>> + }
>> + }
>> +
>> memory_region_unref(section->mr);
>> - if (ret) {
>> - error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
>> - "0x%"HWADDR_PRIx") = %d (%m)",
>> - container, iova, int128_get64(llsize), ret);
>> - }
>>
>> if (container->iommu_type == VFIO_SPAPR_TCE_v2_IOMMU) {
>> vfio_spapr_remove_window(container,
>
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-12 7:05 ` Alexey Kardashevskiy
@ 2018-02-12 16:06 ` Alex Williamson
2018-02-13 1:15 ` Alexey Kardashevskiy
0 siblings, 1 reply; 34+ messages in thread
From: Alex Williamson @ 2018-02-12 16:06 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: David Gibson, qemu-devel, qemu-ppc
On Mon, 12 Feb 2018 18:05:54 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 12/02/18 16:19, David Gibson wrote:
> > On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
> >> At the moment if vfio_memory_listener is registered in the system memory
> >> address space, it maps/unmaps every RAM memory region for DMA.
> >> It expects system page size aligned memory sections so vfio_dma_map
> >> would not fail and so far this has been the case. A mapping failure
> >> would be fatal. A side effect of such behavior is that some MMIO pages
> >> would not be mapped silently.
> >>
> >> However we are going to change MSIX BAR handling so we will end having
> >> non-aligned sections in vfio_memory_listener (more details is in
> >> the next patch) and vfio_dma_map will exit QEMU.
> >>
> >> In order to avoid fatal failures on what previously was not a failure and
> >> was just silently ignored, this checks the section alignment to
> >> the smallest supported IOMMU page size and prints an error if not aligned;
> >> it also prints an error if vfio_dma_map failed despite the page size check.
> >> Both errors are not fatal; only MMIO RAM regions are checked
> >> (aka "RAM device" regions).
> >>
> >> If the amount of errors printed is overwhelming, the MSIX relocation
> >> could be used to avoid excessive error output.
> >>
> >> This is unlikely to cause any behavioral change.
> >>
> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >
> > There are some relatively superficial problems noted below.
> >
> > But more fundamentally, this feels like it's extending an existing
> > hack past the point of usefulness.
> >
> > The explicit check for is_ram_device() here has always bothered me -
> > it's not like a real bus bridge magically knows whether a target
> > address maps to RAM or not.
> >
> > What I think is really going on is that even for systems without an
> > IOMMU, it's not really true to say that the PCI address space maps
> > directly onto address_space_memory. Instead, there's a large, but
> > much less than 2^64 sized, "upstream window" at address 0 on the PCI
> > bus, which is identity mapped to the system bus. Details will vary
> > with the system, but in practice we expect nothing but RAM to be in
> > that window. Addresses not within that window won't be mapped to the
> > system bus but will just be broadcast on the PCI bus and might be
> > picked up as a p2p transaction.
>
> Currently this p2p works only via the IOMMU, direct p2p is not possible as
> the guest needs to know physical MMIO addresses to make p2p work and it
> does not.
/me points to the Direct Translated P2P section of the ACS spec, though
it's as prone to spoofing by the device as ATS. In any case, p2p
reflected from the IOMMU is still p2p and offloads the CPU even if
bandwidth suffers vs bare metal depending on if the data doubles back
over any links. Thanks,
Alex
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-12 16:06 ` Alex Williamson
@ 2018-02-13 1:15 ` Alexey Kardashevskiy
2018-02-13 5:36 ` David Gibson
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-13 1:15 UTC (permalink / raw)
To: Alex Williamson; +Cc: David Gibson, qemu-devel, qemu-ppc
On 13/02/18 03:06, Alex Williamson wrote:
> On Mon, 12 Feb 2018 18:05:54 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
>> On 12/02/18 16:19, David Gibson wrote:
>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>> would not fail and so far this has been the case. A mapping failure
>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>> would not be mapped silently.
>>>>
>>>> However we are going to change MSIX BAR handling so we will end having
>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>
>>>> In order to avoid fatal failures on what previously was not a failure and
>>>> was just silently ignored, this checks the section alignment to
>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>> (aka "RAM device" regions).
>>>>
>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>> could be used to avoid excessive error output.
>>>>
>>>> This is unlikely to cause any behavioral change.
>>>>
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>
>>> There are some relatively superficial problems noted below.
>>>
>>> But more fundamentally, this feels like it's extending an existing
>>> hack past the point of usefulness.
>>>
>>> The explicit check for is_ram_device() here has always bothered me -
>>> it's not like a real bus bridge magically knows whether a target
>>> address maps to RAM or not.
>>>
>>> What I think is really going on is that even for systems without an
>>> IOMMU, it's not really true to say that the PCI address space maps
>>> directly onto address_space_memory. Instead, there's a large, but
>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>> bus, which is identity mapped to the system bus. Details will vary
>>> with the system, but in practice we expect nothing but RAM to be in
>>> that window. Addresses not within that window won't be mapped to the
>>> system bus but will just be broadcast on the PCI bus and might be
>>> picked up as a p2p transaction.
>>
>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>> the guest needs to know physical MMIO addresses to make p2p work and it
>> does not.
>
> /me points to the Direct Translated P2P section of the ACS spec, though
> it's as prone to spoofing by the device as ATS. In any case, p2p
> reflected from the IOMMU is still p2p and offloads the CPU even if
> bandwidth suffers vs bare metal depending on if the data doubles back
> over any links. Thanks,
Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
on the PCI bus, IOMMU needs to be programmed in advance to make this work,
and current that broadcast won't work for the passed through devices.
--
Alexey
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-13 1:15 ` Alexey Kardashevskiy
@ 2018-02-13 5:36 ` David Gibson
2018-02-13 5:41 ` David Gibson
0 siblings, 1 reply; 34+ messages in thread
From: David Gibson @ 2018-02-13 5:36 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Alex Williamson, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 4187 bytes --]
On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
> On 13/02/18 03:06, Alex Williamson wrote:
> > On Mon, 12 Feb 2018 18:05:54 +1100
> > Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >
> >> On 12/02/18 16:19, David Gibson wrote:
> >>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
> >>>> At the moment if vfio_memory_listener is registered in the system memory
> >>>> address space, it maps/unmaps every RAM memory region for DMA.
> >>>> It expects system page size aligned memory sections so vfio_dma_map
> >>>> would not fail and so far this has been the case. A mapping failure
> >>>> would be fatal. A side effect of such behavior is that some MMIO pages
> >>>> would not be mapped silently.
> >>>>
> >>>> However we are going to change MSIX BAR handling so we will end having
> >>>> non-aligned sections in vfio_memory_listener (more details is in
> >>>> the next patch) and vfio_dma_map will exit QEMU.
> >>>>
> >>>> In order to avoid fatal failures on what previously was not a failure and
> >>>> was just silently ignored, this checks the section alignment to
> >>>> the smallest supported IOMMU page size and prints an error if not aligned;
> >>>> it also prints an error if vfio_dma_map failed despite the page size check.
> >>>> Both errors are not fatal; only MMIO RAM regions are checked
> >>>> (aka "RAM device" regions).
> >>>>
> >>>> If the amount of errors printed is overwhelming, the MSIX relocation
> >>>> could be used to avoid excessive error output.
> >>>>
> >>>> This is unlikely to cause any behavioral change.
> >>>>
> >>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>>
> >>> There are some relatively superficial problems noted below.
> >>>
> >>> But more fundamentally, this feels like it's extending an existing
> >>> hack past the point of usefulness.
> >>>
> >>> The explicit check for is_ram_device() here has always bothered me -
> >>> it's not like a real bus bridge magically knows whether a target
> >>> address maps to RAM or not.
> >>>
> >>> What I think is really going on is that even for systems without an
> >>> IOMMU, it's not really true to say that the PCI address space maps
> >>> directly onto address_space_memory. Instead, there's a large, but
> >>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
> >>> bus, which is identity mapped to the system bus. Details will vary
> >>> with the system, but in practice we expect nothing but RAM to be in
> >>> that window. Addresses not within that window won't be mapped to the
> >>> system bus but will just be broadcast on the PCI bus and might be
> >>> picked up as a p2p transaction.
> >>
> >> Currently this p2p works only via the IOMMU, direct p2p is not possible as
> >> the guest needs to know physical MMIO addresses to make p2p work and it
> >> does not.
> >
> > /me points to the Direct Translated P2P section of the ACS spec, though
> > it's as prone to spoofing by the device as ATS. In any case, p2p
> > reflected from the IOMMU is still p2p and offloads the CPU even if
> > bandwidth suffers vs bare metal depending on if the data doubles back
> > over any links. Thanks,
>
> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
> and current that broadcast won't work for the passed through devices.
Well, sure, p2p in a guest with passthrough devices clearly needs to
be translated through the IOMMU (and p2p from a passthrough to an
emulated device is essentially impossible).
But.. what does that have to do with this code. This is the memory
area watcher, looking for memory regions being mapped directly into
the PCI space. NOT IOMMU regions, since those are handled separately
by wiring up the IOMMU notifier. This will only trigger if RAM-like,
non-RAM regions are put into PCI space *not* behind an IOMMMU.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 3/4] vfio-pci: Allow mmap of MSIX BAR
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 3/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
@ 2018-02-13 5:39 ` David Gibson
0 siblings, 0 replies; 34+ messages in thread
From: David Gibson @ 2018-02-13 5:39 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: qemu-devel, qemu-ppc, Alex Williamson
[-- Attachment #1: Type: text/plain, Size: 3832 bytes --]
On Fri, Feb 09, 2018 at 06:55:02PM +1100, Alexey Kardashevskiy wrote:
> At the moment we unconditionally avoid mapping MSIX data of a BAR and
> emulate MSIX table in QEMU. However it is 1) not always necessary as
> a platform may prodive a paravirt interface for MSIX configuration;
> 2) can affect the speed of MMIO access by emulating them in QEMU when
> frequently accessed registers share same system page with MSIX data,
> this is particularly a problem for systems with the page size bigger
> than 4KB.
>
> A new capability - VFIO_REGION_INFO_CAP_MSIX_MAPPABLE - has been added
> to the kernel [1] which tells the userspace that mapping of the MSIX data
> is possible now. This makes use of it so from now on QEMU tries mapping
> the entire BAR as a whole and emulate MSIX on top of that.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a32295c612c57990d17fb0f41e7134394b2f35f6
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> Changes:
> v7:
> * test iova/llsize against pgmask in vfio_listener_region_add/del
> * s/vfio_is_cap_present/vfio_has_region_cap/
> * added comments here and there
> * s/vdev->msix->table_bar/region-nr/
> ---
> include/hw/vfio/vfio-common.h | 1 +
> hw/vfio/common.c | 15 +++++++++++++++
> hw/vfio/pci.c | 9 +++++++++
> 3 files changed, 25 insertions(+)
>
> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> index f3a2ac9..42dd2b0 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> @@ -171,6 +171,7 @@ int vfio_get_region_info(VFIODevice *vbasedev, int index,
> struct vfio_region_info **info);
> int vfio_get_dev_region_info(VFIODevice *vbasedev, uint32_t type,
> uint32_t subtype, struct vfio_region_info **info);
> +bool vfio_has_region_cap(VFIODevice *vbasedev, int region, uint16_t cap_type);
> #endif
> extern const MemoryListener vfio_prereg_listener;
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 736f271..b99ae77 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -1464,6 +1464,21 @@ int vfio_get_dev_region_info(VFIODevice *vbasedev, uint32_t type,
> return -ENODEV;
> }
>
> +bool vfio_has_region_cap(VFIODevice *vbasedev, int region, uint16_t cap_type)
> +{
> + struct vfio_region_info *info = NULL;
> + bool ret = false;
> +
> + if (!vfio_get_region_info(vbasedev, region, &info)) {
> + if (vfio_get_region_info_cap(info, cap_type)) {
> + ret = true;
> + }
> + g_free(info);
> + }
> +
> + return ret;
> +}
> +
> /*
> * Interfaces for IBM EEH (Enhanced Error Handling)
> */
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 879510c..ae9098d 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -1294,6 +1294,15 @@ static void vfio_pci_fixup_msix_region(VFIOPCIDevice *vdev)
> VFIORegion *region = &vdev->bars[vdev->msix->table_bar].region;
>
> /*
> + * If the host driver allows mapping of a MSIX data, we are going to
> + * do map the entire BAR and emulate MSIX table on top of that.
> + */
> + if (vfio_has_region_cap(&vdev->vbasedev, region->nr,
> + VFIO_REGION_INFO_CAP_MSIX_MAPPABLE)) {
> + return;
> + }
> +
> + /*
> * We expect to find a single mmap covering the whole BAR, anything else
> * means it's either unsupported or already setup.
> */
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-13 5:36 ` David Gibson
@ 2018-02-13 5:41 ` David Gibson
2018-02-13 8:20 ` Alexey Kardashevskiy
0 siblings, 1 reply; 34+ messages in thread
From: David Gibson @ 2018-02-13 5:41 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Alex Williamson, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 4762 bytes --]
On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
> > On 13/02/18 03:06, Alex Williamson wrote:
> > > On Mon, 12 Feb 2018 18:05:54 +1100
> > > Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> > >
> > >> On 12/02/18 16:19, David Gibson wrote:
> > >>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
> > >>>> At the moment if vfio_memory_listener is registered in the system memory
> > >>>> address space, it maps/unmaps every RAM memory region for DMA.
> > >>>> It expects system page size aligned memory sections so vfio_dma_map
> > >>>> would not fail and so far this has been the case. A mapping failure
> > >>>> would be fatal. A side effect of such behavior is that some MMIO pages
> > >>>> would not be mapped silently.
> > >>>>
> > >>>> However we are going to change MSIX BAR handling so we will end having
> > >>>> non-aligned sections in vfio_memory_listener (more details is in
> > >>>> the next patch) and vfio_dma_map will exit QEMU.
> > >>>>
> > >>>> In order to avoid fatal failures on what previously was not a failure and
> > >>>> was just silently ignored, this checks the section alignment to
> > >>>> the smallest supported IOMMU page size and prints an error if not aligned;
> > >>>> it also prints an error if vfio_dma_map failed despite the page size check.
> > >>>> Both errors are not fatal; only MMIO RAM regions are checked
> > >>>> (aka "RAM device" regions).
> > >>>>
> > >>>> If the amount of errors printed is overwhelming, the MSIX relocation
> > >>>> could be used to avoid excessive error output.
> > >>>>
> > >>>> This is unlikely to cause any behavioral change.
> > >>>>
> > >>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > >>>
> > >>> There are some relatively superficial problems noted below.
> > >>>
> > >>> But more fundamentally, this feels like it's extending an existing
> > >>> hack past the point of usefulness.
> > >>>
> > >>> The explicit check for is_ram_device() here has always bothered me -
> > >>> it's not like a real bus bridge magically knows whether a target
> > >>> address maps to RAM or not.
> > >>>
> > >>> What I think is really going on is that even for systems without an
> > >>> IOMMU, it's not really true to say that the PCI address space maps
> > >>> directly onto address_space_memory. Instead, there's a large, but
> > >>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
> > >>> bus, which is identity mapped to the system bus. Details will vary
> > >>> with the system, but in practice we expect nothing but RAM to be in
> > >>> that window. Addresses not within that window won't be mapped to the
> > >>> system bus but will just be broadcast on the PCI bus and might be
> > >>> picked up as a p2p transaction.
> > >>
> > >> Currently this p2p works only via the IOMMU, direct p2p is not possible as
> > >> the guest needs to know physical MMIO addresses to make p2p work and it
> > >> does not.
> > >
> > > /me points to the Direct Translated P2P section of the ACS spec, though
> > > it's as prone to spoofing by the device as ATS. In any case, p2p
> > > reflected from the IOMMU is still p2p and offloads the CPU even if
> > > bandwidth suffers vs bare metal depending on if the data doubles back
> > > over any links. Thanks,
> >
> > Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
> > on the PCI bus, IOMMU needs to be programmed in advance to make this work,
> > and current that broadcast won't work for the passed through devices.
>
> Well, sure, p2p in a guest with passthrough devices clearly needs to
> be translated through the IOMMU (and p2p from a passthrough to an
> emulated device is essentially impossible).
>
> But.. what does that have to do with this code. This is the memory
> area watcher, looking for memory regions being mapped directly into
> the PCI space. NOT IOMMU regions, since those are handled separately
> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
> non-RAM regions are put into PCI space *not* behind an IOMMMU.
Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
the point here is that this will map RAM-like devices into the host
IOMMU when there is no guest IOMMU, allowing p2p transactions between
passthrough devices (though not from passthrough to emulated devices).
The conditions still seem kind of awkward to me, but I guess it makes
sense.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 4/4] ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 4/4] ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices Alexey Kardashevskiy
@ 2018-02-13 5:43 ` David Gibson
0 siblings, 0 replies; 34+ messages in thread
From: David Gibson @ 2018-02-13 5:43 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: qemu-devel, qemu-ppc, Alex Williamson
[-- Attachment #1: Type: text/plain, Size: 3223 bytes --]
On Fri, Feb 09, 2018 at 06:55:03PM +1100, Alexey Kardashevskiy wrote:
> This adds a possibility for the platform to tell VFIO not to emulate MSIX
> so MMIO memory regions do not get split into chunks in flatview and
> the entire page can be registered as a KVM memory slot and make direct
> MMIO access possible for the guest.
>
> This enables the entire MSIX BAR mapping to the guest for the pseries
> platform in order to achieve the maximum MMIO preformance for certain
> devices.
>
> Tested on:
> LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
I still think having the property on the machine is an uglier option
than having it on the device, but Alex didn't like that, so I'll roll
with it.
Reivewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>
> Need to split this in two?
> ---
> hw/ppc/spapr.c | 7 +++++++
> hw/vfio/pci.c | 13 +++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index eb3e1a7..14d8ecb 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2855,6 +2855,11 @@ static void spapr_set_modern_hotplug_events(Object *obj, bool value,
> spapr->use_hotplug_event_source = value;
> }
>
> +static bool spapr_get_msix_emulation(Object *obj, Error **errp)
> +{
> + return true;
> +}
> +
> static char *spapr_get_resize_hpt(Object *obj, Error **errp)
> {
> sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> @@ -2936,6 +2941,8 @@ static void spapr_instance_init(Object *obj)
> object_property_set_description(obj, "vsmt",
> "Virtual SMT: KVM behaves as if this were"
> " the host's SMT mode", &error_abort);
> + object_property_add_bool(obj, "vfio-no-msix-emulation",
> + spapr_get_msix_emulation, NULL, NULL);
> }
>
> static void spapr_machine_finalizefn(Object *obj)
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index ae9098d..4a03085 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -1580,6 +1580,19 @@ static int vfio_msix_setup(VFIOPCIDevice *vdev, int pos, Error **errp)
> */
> memory_region_set_enabled(&vdev->pdev.msix_pba_mmio, false);
>
> + /*
> + * The emulated machine may provide a paravirt interface for MSIX setup
> + * so it is not strictly necessary to emulate MSIX here. This becomes
> + * helpful when frequently accessed MMIO registers are located in
> + * subpages adjacent to the MSIX table but the MSIX data containing page
> + * cannot be mapped because of a host page size bigger than the MSIX table
> + * alignment.
> + */
> + if (object_property_get_bool(OBJECT(qdev_get_machine()),
> + "vfio-no-msix-emulation", NULL)) {
> + memory_region_set_enabled(&vdev->pdev.msix_table_mmio, false);
> + }
> +
> return 0;
> }
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-13 5:41 ` David Gibson
@ 2018-02-13 8:20 ` Alexey Kardashevskiy
2018-02-14 1:33 ` David Gibson
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-13 8:20 UTC (permalink / raw)
To: David Gibson; +Cc: Alex Williamson, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 4822 bytes --]
On 13/02/18 16:41, David Gibson wrote:
> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
>>> On 13/02/18 03:06, Alex Williamson wrote:
>>>> On Mon, 12 Feb 2018 18:05:54 +1100
>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>
>>>>> On 12/02/18 16:19, David Gibson wrote:
>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>>>>> would not fail and so far this has been the case. A mapping failure
>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>>>>> would not be mapped silently.
>>>>>>>
>>>>>>> However we are going to change MSIX BAR handling so we will end having
>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>>>>
>>>>>>> In order to avoid fatal failures on what previously was not a failure and
>>>>>>> was just silently ignored, this checks the section alignment to
>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>>>>> (aka "RAM device" regions).
>>>>>>>
>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>>>>> could be used to avoid excessive error output.
>>>>>>>
>>>>>>> This is unlikely to cause any behavioral change.
>>>>>>>
>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>
>>>>>> There are some relatively superficial problems noted below.
>>>>>>
>>>>>> But more fundamentally, this feels like it's extending an existing
>>>>>> hack past the point of usefulness.
>>>>>>
>>>>>> The explicit check for is_ram_device() here has always bothered me -
>>>>>> it's not like a real bus bridge magically knows whether a target
>>>>>> address maps to RAM or not.
>>>>>>
>>>>>> What I think is really going on is that even for systems without an
>>>>>> IOMMU, it's not really true to say that the PCI address space maps
>>>>>> directly onto address_space_memory. Instead, there's a large, but
>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>>>>> bus, which is identity mapped to the system bus. Details will vary
>>>>>> with the system, but in practice we expect nothing but RAM to be in
>>>>>> that window. Addresses not within that window won't be mapped to the
>>>>>> system bus but will just be broadcast on the PCI bus and might be
>>>>>> picked up as a p2p transaction.
>>>>>
>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
>>>>> does not.
>>>>
>>>> /me points to the Direct Translated P2P section of the ACS spec, though
>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
>>>> bandwidth suffers vs bare metal depending on if the data doubles back
>>>> over any links. Thanks,
>>>
>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
>>> and current that broadcast won't work for the passed through devices.
>>
>> Well, sure, p2p in a guest with passthrough devices clearly needs to
>> be translated through the IOMMU (and p2p from a passthrough to an
>> emulated device is essentially impossible).
>>
>> But.. what does that have to do with this code. This is the memory
>> area watcher, looking for memory regions being mapped directly into
>> the PCI space. NOT IOMMU regions, since those are handled separately
>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
>
> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
> the point here is that this will map RAM-like devices into the host
> IOMMU when there is no guest IOMMU, allowing p2p transactions between
> passthrough devices (though not from passthrough to emulated devices).
Correct.
>
> The conditions still seem kind of awkward to me, but I guess it makes
> sense.
Is it the time to split this listener to RAM-listener and PCI bus listener?
On x86 it listens on the "memory" AS, on spapr - on the
"pci@800000020000000" AS, this will just create more confusion over time...
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-13 8:20 ` Alexey Kardashevskiy
@ 2018-02-14 1:33 ` David Gibson
2018-02-14 8:09 ` Alexey Kardashevskiy
0 siblings, 1 reply; 34+ messages in thread
From: David Gibson @ 2018-02-14 1:33 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Alex Williamson, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 5816 bytes --]
On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
> On 13/02/18 16:41, David Gibson wrote:
> > On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
> >> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
> >>> On 13/02/18 03:06, Alex Williamson wrote:
> >>>> On Mon, 12 Feb 2018 18:05:54 +1100
> >>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >>>>
> >>>>> On 12/02/18 16:19, David Gibson wrote:
> >>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
> >>>>>>> At the moment if vfio_memory_listener is registered in the system memory
> >>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
> >>>>>>> It expects system page size aligned memory sections so vfio_dma_map
> >>>>>>> would not fail and so far this has been the case. A mapping failure
> >>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
> >>>>>>> would not be mapped silently.
> >>>>>>>
> >>>>>>> However we are going to change MSIX BAR handling so we will end having
> >>>>>>> non-aligned sections in vfio_memory_listener (more details is in
> >>>>>>> the next patch) and vfio_dma_map will exit QEMU.
> >>>>>>>
> >>>>>>> In order to avoid fatal failures on what previously was not a failure and
> >>>>>>> was just silently ignored, this checks the section alignment to
> >>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
> >>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
> >>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
> >>>>>>> (aka "RAM device" regions).
> >>>>>>>
> >>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
> >>>>>>> could be used to avoid excessive error output.
> >>>>>>>
> >>>>>>> This is unlikely to cause any behavioral change.
> >>>>>>>
> >>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>>>>>
> >>>>>> There are some relatively superficial problems noted below.
> >>>>>>
> >>>>>> But more fundamentally, this feels like it's extending an existing
> >>>>>> hack past the point of usefulness.
> >>>>>>
> >>>>>> The explicit check for is_ram_device() here has always bothered me -
> >>>>>> it's not like a real bus bridge magically knows whether a target
> >>>>>> address maps to RAM or not.
> >>>>>>
> >>>>>> What I think is really going on is that even for systems without an
> >>>>>> IOMMU, it's not really true to say that the PCI address space maps
> >>>>>> directly onto address_space_memory. Instead, there's a large, but
> >>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
> >>>>>> bus, which is identity mapped to the system bus. Details will vary
> >>>>>> with the system, but in practice we expect nothing but RAM to be in
> >>>>>> that window. Addresses not within that window won't be mapped to the
> >>>>>> system bus but will just be broadcast on the PCI bus and might be
> >>>>>> picked up as a p2p transaction.
> >>>>>
> >>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
> >>>>> the guest needs to know physical MMIO addresses to make p2p work and it
> >>>>> does not.
> >>>>
> >>>> /me points to the Direct Translated P2P section of the ACS spec, though
> >>>> it's as prone to spoofing by the device as ATS. In any case, p2p
> >>>> reflected from the IOMMU is still p2p and offloads the CPU even if
> >>>> bandwidth suffers vs bare metal depending on if the data doubles back
> >>>> over any links. Thanks,
> >>>
> >>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
> >>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
> >>> and current that broadcast won't work for the passed through devices.
> >>
> >> Well, sure, p2p in a guest with passthrough devices clearly needs to
> >> be translated through the IOMMU (and p2p from a passthrough to an
> >> emulated device is essentially impossible).
> >>
> >> But.. what does that have to do with this code. This is the memory
> >> area watcher, looking for memory regions being mapped directly into
> >> the PCI space. NOT IOMMU regions, since those are handled separately
> >> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
> >> non-RAM regions are put into PCI space *not* behind an IOMMMU.
> >
> > Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
> > the point here is that this will map RAM-like devices into the host
> > IOMMU when there is no guest IOMMU, allowing p2p transactions between
> > passthrough devices (though not from passthrough to emulated devices).
>
> Correct.
>
> >
> > The conditions still seem kind of awkward to me, but I guess it makes
> > sense.
>
> Is it the time to split this listener to RAM-listener and PCI bus listener?
I'm not really sure what you mean by that.
> On x86 it listens on the "memory" AS, on spapr - on the
> "pci@800000020000000" AS, this will just create more confusion over time...
Hm, it's still logically the same AS in each case - the PCI address
space. It's just that in the x86 case that happens to be the same as
the memory AS (at least when there isn't a guest side IOMMU).
I do wonder if that's really right even for x86 without IOMMU. The
PCI address space is identity mapped to the "main" memory address
space there, but I'm not sure it's mapped th *all* of the main memory
address space, probably just certain ranges of it. That's what I was
suggesting earlier in the thread.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-14 1:33 ` David Gibson
@ 2018-02-14 8:09 ` Alexey Kardashevskiy
2018-02-14 15:55 ` Alex Williamson
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-14 8:09 UTC (permalink / raw)
To: David Gibson; +Cc: Alex Williamson, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 5950 bytes --]
On 14/02/18 12:33, David Gibson wrote:
> On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
>> On 13/02/18 16:41, David Gibson wrote:
>>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
>>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
>>>>> On 13/02/18 03:06, Alex Williamson wrote:
>>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>
>>>>>>> On 12/02/18 16:19, David Gibson wrote:
>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>>>>>>> would not fail and so far this has been the case. A mapping failure
>>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>>>>>>> would not be mapped silently.
>>>>>>>>>
>>>>>>>>> However we are going to change MSIX BAR handling so we will end having
>>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>>>>>>
>>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
>>>>>>>>> was just silently ignored, this checks the section alignment to
>>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>>>>>>> (aka "RAM device" regions).
>>>>>>>>>
>>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>>>>>>> could be used to avoid excessive error output.
>>>>>>>>>
>>>>>>>>> This is unlikely to cause any behavioral change.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>>>
>>>>>>>> There are some relatively superficial problems noted below.
>>>>>>>>
>>>>>>>> But more fundamentally, this feels like it's extending an existing
>>>>>>>> hack past the point of usefulness.
>>>>>>>>
>>>>>>>> The explicit check for is_ram_device() here has always bothered me -
>>>>>>>> it's not like a real bus bridge magically knows whether a target
>>>>>>>> address maps to RAM or not.
>>>>>>>>
>>>>>>>> What I think is really going on is that even for systems without an
>>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
>>>>>>>> directly onto address_space_memory. Instead, there's a large, but
>>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>>>>>>> bus, which is identity mapped to the system bus. Details will vary
>>>>>>>> with the system, but in practice we expect nothing but RAM to be in
>>>>>>>> that window. Addresses not within that window won't be mapped to the
>>>>>>>> system bus but will just be broadcast on the PCI bus and might be
>>>>>>>> picked up as a p2p transaction.
>>>>>>>
>>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
>>>>>>> does not.
>>>>>>
>>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
>>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
>>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
>>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
>>>>>> over any links. Thanks,
>>>>>
>>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
>>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
>>>>> and current that broadcast won't work for the passed through devices.
>>>>
>>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
>>>> be translated through the IOMMU (and p2p from a passthrough to an
>>>> emulated device is essentially impossible).
>>>>
>>>> But.. what does that have to do with this code. This is the memory
>>>> area watcher, looking for memory regions being mapped directly into
>>>> the PCI space. NOT IOMMU regions, since those are handled separately
>>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
>>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
>>>
>>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
>>> the point here is that this will map RAM-like devices into the host
>>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
>>> passthrough devices (though not from passthrough to emulated devices).
>>
>> Correct.
>>
>>>
>>> The conditions still seem kind of awkward to me, but I guess it makes
>>> sense.
>>
>> Is it the time to split this listener to RAM-listener and PCI bus listener?
>
> I'm not really sure what you mean by that.
>
>> On x86 it listens on the "memory" AS, on spapr - on the
>> "pci@800000020000000" AS, this will just create more confusion over time...
>
> Hm, it's still logically the same AS in each case - the PCI address
> space. It's just that in the x86 case that happens to be the same as
> the memory AS (at least when there isn't a guest side IOMMU).
Hm. Ok.
> I do wonder if that's really right even for x86 without IOMMU. The
> PCI address space is identity mapped to the "main" memory address
> space there, but I'm not sure it's mapped th *all* of the main memory
What should have been in the place of "th" above? :)
> address space, probably just certain ranges of it. That's what I was
> suggesting earlier in the thread.
afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
anything like that. I am trying to figure out what is not correct with the
patch. Thanks,
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-14 8:09 ` Alexey Kardashevskiy
@ 2018-02-14 15:55 ` Alex Williamson
2018-02-16 5:28 ` David Gibson
0 siblings, 1 reply; 34+ messages in thread
From: Alex Williamson @ 2018-02-14 15:55 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: David Gibson, qemu-devel, qemu-ppc
On Wed, 14 Feb 2018 19:09:16 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 14/02/18 12:33, David Gibson wrote:
> > On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
> >> On 13/02/18 16:41, David Gibson wrote:
> >>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
> >>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
> >>>>> On 13/02/18 03:06, Alex Williamson wrote:
> >>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
> >>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >>>>>>
> >>>>>>> On 12/02/18 16:19, David Gibson wrote:
> >>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
> >>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
> >>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
> >>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
> >>>>>>>>> would not fail and so far this has been the case. A mapping failure
> >>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
> >>>>>>>>> would not be mapped silently.
> >>>>>>>>>
> >>>>>>>>> However we are going to change MSIX BAR handling so we will end having
> >>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
> >>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
> >>>>>>>>>
> >>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
> >>>>>>>>> was just silently ignored, this checks the section alignment to
> >>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
> >>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
> >>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
> >>>>>>>>> (aka "RAM device" regions).
> >>>>>>>>>
> >>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
> >>>>>>>>> could be used to avoid excessive error output.
> >>>>>>>>>
> >>>>>>>>> This is unlikely to cause any behavioral change.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>>>>>>>
> >>>>>>>> There are some relatively superficial problems noted below.
> >>>>>>>>
> >>>>>>>> But more fundamentally, this feels like it's extending an existing
> >>>>>>>> hack past the point of usefulness.
> >>>>>>>>
> >>>>>>>> The explicit check for is_ram_device() here has always bothered me -
> >>>>>>>> it's not like a real bus bridge magically knows whether a target
> >>>>>>>> address maps to RAM or not.
> >>>>>>>>
> >>>>>>>> What I think is really going on is that even for systems without an
> >>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
> >>>>>>>> directly onto address_space_memory. Instead, there's a large, but
> >>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
> >>>>>>>> bus, which is identity mapped to the system bus. Details will vary
> >>>>>>>> with the system, but in practice we expect nothing but RAM to be in
> >>>>>>>> that window. Addresses not within that window won't be mapped to the
> >>>>>>>> system bus but will just be broadcast on the PCI bus and might be
> >>>>>>>> picked up as a p2p transaction.
> >>>>>>>
> >>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
> >>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
> >>>>>>> does not.
> >>>>>>
> >>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
> >>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
> >>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
> >>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
> >>>>>> over any links. Thanks,
> >>>>>
> >>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
> >>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
> >>>>> and current that broadcast won't work for the passed through devices.
> >>>>
> >>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
> >>>> be translated through the IOMMU (and p2p from a passthrough to an
> >>>> emulated device is essentially impossible).
> >>>>
> >>>> But.. what does that have to do with this code. This is the memory
> >>>> area watcher, looking for memory regions being mapped directly into
> >>>> the PCI space. NOT IOMMU regions, since those are handled separately
> >>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
> >>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
> >>>
> >>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
> >>> the point here is that this will map RAM-like devices into the host
> >>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
> >>> passthrough devices (though not from passthrough to emulated devices).
> >>
> >> Correct.
> >>
> >>>
> >>> The conditions still seem kind of awkward to me, but I guess it makes
> >>> sense.
> >>
> >> Is it the time to split this listener to RAM-listener and PCI bus listener?
> >
> > I'm not really sure what you mean by that.
> >
> >> On x86 it listens on the "memory" AS, on spapr - on the
> >> "pci@800000020000000" AS, this will just create more confusion over time...
> >
> > Hm, it's still logically the same AS in each case - the PCI address
> > space. It's just that in the x86 case that happens to be the same as
> > the memory AS (at least when there isn't a guest side IOMMU).
>
> Hm. Ok.
>
> > I do wonder if that's really right even for x86 without IOMMU. The
> > PCI address space is identity mapped to the "main" memory address
> > space there, but I'm not sure it's mapped th *all* of the main memory
>
> What should have been in the place of "th" above? :)
>
> > address space, probably just certain ranges of it. That's what I was
> > suggesting earlier in the thread.
>
> afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
> anything like that. I am trying to figure out what is not correct with the
> patch. Thanks,
It is possible for x86 systems to have translation applied to MMIO vs
RAM such that the processor view and device view of MMIO are different,
putting them into separate address spaces, but this is not typical and
not available on the class of chipsets that QEMU emulates for PC.
Therefore I think it's correct that MMIO and RAM all live in one big
happy, flat address space as they do now (assuming the guest IOMMU is
not present or disabled). Thanks,
Alex
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-14 15:55 ` Alex Williamson
@ 2018-02-16 5:28 ` David Gibson
2018-02-19 2:46 ` Alexey Kardashevskiy
0 siblings, 1 reply; 34+ messages in thread
From: David Gibson @ 2018-02-16 5:28 UTC (permalink / raw)
To: Alex Williamson; +Cc: Alexey Kardashevskiy, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 8218 bytes --]
On Wed, Feb 14, 2018 at 08:55:41AM -0700, Alex Williamson wrote:
> On Wed, 14 Feb 2018 19:09:16 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
> > On 14/02/18 12:33, David Gibson wrote:
> > > On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
> > >> On 13/02/18 16:41, David Gibson wrote:
> > >>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
> > >>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
> > >>>>> On 13/02/18 03:06, Alex Williamson wrote:
> > >>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
> > >>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> > >>>>>>
> > >>>>>>> On 12/02/18 16:19, David Gibson wrote:
> > >>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
> > >>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
> > >>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
> > >>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
> > >>>>>>>>> would not fail and so far this has been the case. A mapping failure
> > >>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
> > >>>>>>>>> would not be mapped silently.
> > >>>>>>>>>
> > >>>>>>>>> However we are going to change MSIX BAR handling so we will end having
> > >>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
> > >>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
> > >>>>>>>>>
> > >>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
> > >>>>>>>>> was just silently ignored, this checks the section alignment to
> > >>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
> > >>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
> > >>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
> > >>>>>>>>> (aka "RAM device" regions).
> > >>>>>>>>>
> > >>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
> > >>>>>>>>> could be used to avoid excessive error output.
> > >>>>>>>>>
> > >>>>>>>>> This is unlikely to cause any behavioral change.
> > >>>>>>>>>
> > >>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > >>>>>>>>
> > >>>>>>>> There are some relatively superficial problems noted below.
> > >>>>>>>>
> > >>>>>>>> But more fundamentally, this feels like it's extending an existing
> > >>>>>>>> hack past the point of usefulness.
> > >>>>>>>>
> > >>>>>>>> The explicit check for is_ram_device() here has always bothered me -
> > >>>>>>>> it's not like a real bus bridge magically knows whether a target
> > >>>>>>>> address maps to RAM or not.
> > >>>>>>>>
> > >>>>>>>> What I think is really going on is that even for systems without an
> > >>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
> > >>>>>>>> directly onto address_space_memory. Instead, there's a large, but
> > >>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
> > >>>>>>>> bus, which is identity mapped to the system bus. Details will vary
> > >>>>>>>> with the system, but in practice we expect nothing but RAM to be in
> > >>>>>>>> that window. Addresses not within that window won't be mapped to the
> > >>>>>>>> system bus but will just be broadcast on the PCI bus and might be
> > >>>>>>>> picked up as a p2p transaction.
> > >>>>>>>
> > >>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
> > >>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
> > >>>>>>> does not.
> > >>>>>>
> > >>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
> > >>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
> > >>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
> > >>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
> > >>>>>> over any links. Thanks,
> > >>>>>
> > >>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
> > >>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
> > >>>>> and current that broadcast won't work for the passed through devices.
> > >>>>
> > >>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
> > >>>> be translated through the IOMMU (and p2p from a passthrough to an
> > >>>> emulated device is essentially impossible).
> > >>>>
> > >>>> But.. what does that have to do with this code. This is the memory
> > >>>> area watcher, looking for memory regions being mapped directly into
> > >>>> the PCI space. NOT IOMMU regions, since those are handled separately
> > >>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
> > >>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
> > >>>
> > >>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
> > >>> the point here is that this will map RAM-like devices into the host
> > >>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
> > >>> passthrough devices (though not from passthrough to emulated devices).
> > >>
> > >> Correct.
> > >>
> > >>>
> > >>> The conditions still seem kind of awkward to me, but I guess it makes
> > >>> sense.
> > >>
> > >> Is it the time to split this listener to RAM-listener and PCI bus listener?
> > >
> > > I'm not really sure what you mean by that.
> > >
> > >> On x86 it listens on the "memory" AS, on spapr - on the
> > >> "pci@800000020000000" AS, this will just create more confusion over time...
> > >
> > > Hm, it's still logically the same AS in each case - the PCI address
> > > space. It's just that in the x86 case that happens to be the same as
> > > the memory AS (at least when there isn't a guest side IOMMU).
> >
> > Hm. Ok.
> >
> > > I do wonder if that's really right even for x86 without IOMMU. The
> > > PCI address space is identity mapped to the "main" memory address
> > > space there, but I'm not sure it's mapped th *all* of the main memory
> >
> > What should have been in the place of "th" above? :)
> >
> > > address space, probably just certain ranges of it. That's what I was
> > > suggesting earlier in the thread.
> >
> > afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
> > anything like that. I am trying to figure out what is not correct with the
> > patch. Thanks,
>
> It is possible for x86 systems to have translation applied to MMIO vs
> RAM such that the processor view and device view of MMIO are different,
> putting them into separate address spaces, but this is not typical and
> not available on the class of chipsets that QEMU emulates for PC.
> Therefore I think it's correct that MMIO and RAM all live in one big
> happy, flat address space as they do now (assuming the guest IOMMU is
> not present or disabled). Thanks,
Ah.. I think the thing I was missing is that on PC (at least with
typical chipsets) *all* MMIO essentially comes from PCI space. Even
the legacy devices are essentially ISA which is treated as being on a
bridge under the PCI space. On non-x86 there are often at least a
handful of MMIO devices that aren't within the PCI space - say, the
PCI host bridge itself at least. x86 avoids that by using the
separate IO space, which is also a bit weird in that it's
simultaneously direct attached to the cpu (and so doesn't need bridge
configuration), but also identified with the legay IO space treated as
being under two bridges (host->PCI, PCI->ISA) for other purposes.
Maybe it's just me, but I find it makes more sense to me if I think of
it as the two ASes being equal because on PC the system address map
(address_space_memory) is made equal to the PCI address map, rather
than the PCI address map being made equal to the system one.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-16 5:28 ` David Gibson
@ 2018-02-19 2:46 ` Alexey Kardashevskiy
2018-02-26 8:36 ` Alexey Kardashevskiy
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-19 2:46 UTC (permalink / raw)
To: David Gibson, Alex Williamson; +Cc: qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 8380 bytes --]
On 16/02/18 16:28, David Gibson wrote:
> On Wed, Feb 14, 2018 at 08:55:41AM -0700, Alex Williamson wrote:
>> On Wed, 14 Feb 2018 19:09:16 +1100
>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>
>>> On 14/02/18 12:33, David Gibson wrote:
>>>> On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
>>>>> On 13/02/18 16:41, David Gibson wrote:
>>>>>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
>>>>>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>> On 13/02/18 03:06, Alex Williamson wrote:
>>>>>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
>>>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>>>
>>>>>>>>>> On 12/02/18 16:19, David Gibson wrote:
>>>>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>>>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>>>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>>>>>>>>>> would not fail and so far this has been the case. A mapping failure
>>>>>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>>>>>>>>>> would not be mapped silently.
>>>>>>>>>>>>
>>>>>>>>>>>> However we are going to change MSIX BAR handling so we will end having
>>>>>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>>>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>>>>>>>>>
>>>>>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
>>>>>>>>>>>> was just silently ignored, this checks the section alignment to
>>>>>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>>>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>>>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>>>>>>>>>> (aka "RAM device" regions).
>>>>>>>>>>>>
>>>>>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>>>>>>>>>> could be used to avoid excessive error output.
>>>>>>>>>>>>
>>>>>>>>>>>> This is unlikely to cause any behavioral change.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>>>>>>
>>>>>>>>>>> There are some relatively superficial problems noted below.
>>>>>>>>>>>
>>>>>>>>>>> But more fundamentally, this feels like it's extending an existing
>>>>>>>>>>> hack past the point of usefulness.
>>>>>>>>>>>
>>>>>>>>>>> The explicit check for is_ram_device() here has always bothered me -
>>>>>>>>>>> it's not like a real bus bridge magically knows whether a target
>>>>>>>>>>> address maps to RAM or not.
>>>>>>>>>>>
>>>>>>>>>>> What I think is really going on is that even for systems without an
>>>>>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
>>>>>>>>>>> directly onto address_space_memory. Instead, there's a large, but
>>>>>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>>>>>>>>>> bus, which is identity mapped to the system bus. Details will vary
>>>>>>>>>>> with the system, but in practice we expect nothing but RAM to be in
>>>>>>>>>>> that window. Addresses not within that window won't be mapped to the
>>>>>>>>>>> system bus but will just be broadcast on the PCI bus and might be
>>>>>>>>>>> picked up as a p2p transaction.
>>>>>>>>>>
>>>>>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>>>>>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
>>>>>>>>>> does not.
>>>>>>>>>
>>>>>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
>>>>>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
>>>>>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
>>>>>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
>>>>>>>>> over any links. Thanks,
>>>>>>>>
>>>>>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
>>>>>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
>>>>>>>> and current that broadcast won't work for the passed through devices.
>>>>>>>
>>>>>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
>>>>>>> be translated through the IOMMU (and p2p from a passthrough to an
>>>>>>> emulated device is essentially impossible).
>>>>>>>
>>>>>>> But.. what does that have to do with this code. This is the memory
>>>>>>> area watcher, looking for memory regions being mapped directly into
>>>>>>> the PCI space. NOT IOMMU regions, since those are handled separately
>>>>>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
>>>>>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
>>>>>>
>>>>>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
>>>>>> the point here is that this will map RAM-like devices into the host
>>>>>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
>>>>>> passthrough devices (though not from passthrough to emulated devices).
>>>>>
>>>>> Correct.
>>>>>
>>>>>>
>>>>>> The conditions still seem kind of awkward to me, but I guess it makes
>>>>>> sense.
>>>>>
>>>>> Is it the time to split this listener to RAM-listener and PCI bus listener?
>>>>
>>>> I'm not really sure what you mean by that.
>>>>
>>>>> On x86 it listens on the "memory" AS, on spapr - on the
>>>>> "pci@800000020000000" AS, this will just create more confusion over time...
>>>>
>>>> Hm, it's still logically the same AS in each case - the PCI address
>>>> space. It's just that in the x86 case that happens to be the same as
>>>> the memory AS (at least when there isn't a guest side IOMMU).
>>>
>>> Hm. Ok.
>>>
>>>> I do wonder if that's really right even for x86 without IOMMU. The
>>>> PCI address space is identity mapped to the "main" memory address
>>>> space there, but I'm not sure it's mapped th *all* of the main memory
>>>
>>> What should have been in the place of "th" above? :)
>>>
>>>> address space, probably just certain ranges of it. That's what I was
>>>> suggesting earlier in the thread.
>>>
>>> afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
>>> anything like that. I am trying to figure out what is not correct with the
>>> patch. Thanks,
>>
>> It is possible for x86 systems to have translation applied to MMIO vs
>> RAM such that the processor view and device view of MMIO are different,
>> putting them into separate address spaces, but this is not typical and
>> not available on the class of chipsets that QEMU emulates for PC.
>> Therefore I think it's correct that MMIO and RAM all live in one big
>> happy, flat address space as they do now (assuming the guest IOMMU is
>> not present or disabled). Thanks,
>
> Ah.. I think the thing I was missing is that on PC (at least with
> typical chipsets) *all* MMIO essentially comes from PCI space. Even
> the legacy devices are essentially ISA which is treated as being on a
> bridge under the PCI space. On non-x86 there are often at least a
> handful of MMIO devices that aren't within the PCI space - say, the
> PCI host bridge itself at least. x86 avoids that by using the
> separate IO space, which is also a bit weird in that it's
> simultaneously direct attached to the cpu (and so doesn't need bridge
> configuration), but also identified with the legay IO space treated as
> being under two bridges (host->PCI, PCI->ISA) for other purposes.
>
> Maybe it's just me, but I find it makes more sense to me if I think of
> it as the two ASes being equal because on PC the system address map
> (address_space_memory) is made equal to the PCI address map, rather
> than the PCI address map being made equal to the system one.
It makes more sense to me too, we just do not exploit/expose this on SPAPR
- the PCI address space only has 2xIOMMU and 1xMSI windows and that's it,
no MMIO which is mapped to the system AS only (adding those to the PCI AS
is little tricky as mentioned elsewhere).
Anyway, I still wonder - what needs to be addressed in the 2/4 patch in
order to proceed?
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-19 2:46 ` Alexey Kardashevskiy
@ 2018-02-26 8:36 ` Alexey Kardashevskiy
2018-03-07 2:17 ` Alexey Kardashevskiy
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-02-26 8:36 UTC (permalink / raw)
To: David Gibson, Alex Williamson; +Cc: qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 8596 bytes --]
On 19/02/18 13:46, Alexey Kardashevskiy wrote:
> On 16/02/18 16:28, David Gibson wrote:
>> On Wed, Feb 14, 2018 at 08:55:41AM -0700, Alex Williamson wrote:
>>> On Wed, 14 Feb 2018 19:09:16 +1100
>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>
>>>> On 14/02/18 12:33, David Gibson wrote:
>>>>> On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
>>>>>> On 13/02/18 16:41, David Gibson wrote:
>>>>>>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
>>>>>>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>> On 13/02/18 03:06, Alex Williamson wrote:
>>>>>>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
>>>>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 12/02/18 16:19, David Gibson wrote:
>>>>>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>>>>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>>>>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>>>>>>>>>>> would not fail and so far this has been the case. A mapping failure
>>>>>>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>>>>>>>>>>> would not be mapped silently.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However we are going to change MSIX BAR handling so we will end having
>>>>>>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>>>>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
>>>>>>>>>>>>> was just silently ignored, this checks the section alignment to
>>>>>>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>>>>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>>>>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>>>>>>>>>>> (aka "RAM device" regions).
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>>>>>>>>>>> could be used to avoid excessive error output.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is unlikely to cause any behavioral change.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>>>>>>>
>>>>>>>>>>>> There are some relatively superficial problems noted below.
>>>>>>>>>>>>
>>>>>>>>>>>> But more fundamentally, this feels like it's extending an existing
>>>>>>>>>>>> hack past the point of usefulness.
>>>>>>>>>>>>
>>>>>>>>>>>> The explicit check for is_ram_device() here has always bothered me -
>>>>>>>>>>>> it's not like a real bus bridge magically knows whether a target
>>>>>>>>>>>> address maps to RAM or not.
>>>>>>>>>>>>
>>>>>>>>>>>> What I think is really going on is that even for systems without an
>>>>>>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
>>>>>>>>>>>> directly onto address_space_memory. Instead, there's a large, but
>>>>>>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>>>>>>>>>>> bus, which is identity mapped to the system bus. Details will vary
>>>>>>>>>>>> with the system, but in practice we expect nothing but RAM to be in
>>>>>>>>>>>> that window. Addresses not within that window won't be mapped to the
>>>>>>>>>>>> system bus but will just be broadcast on the PCI bus and might be
>>>>>>>>>>>> picked up as a p2p transaction.
>>>>>>>>>>>
>>>>>>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>>>>>>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
>>>>>>>>>>> does not.
>>>>>>>>>>
>>>>>>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
>>>>>>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
>>>>>>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
>>>>>>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
>>>>>>>>>> over any links. Thanks,
>>>>>>>>>
>>>>>>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
>>>>>>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
>>>>>>>>> and current that broadcast won't work for the passed through devices.
>>>>>>>>
>>>>>>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
>>>>>>>> be translated through the IOMMU (and p2p from a passthrough to an
>>>>>>>> emulated device is essentially impossible).
>>>>>>>>
>>>>>>>> But.. what does that have to do with this code. This is the memory
>>>>>>>> area watcher, looking for memory regions being mapped directly into
>>>>>>>> the PCI space. NOT IOMMU regions, since those are handled separately
>>>>>>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
>>>>>>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
>>>>>>>
>>>>>>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
>>>>>>> the point here is that this will map RAM-like devices into the host
>>>>>>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
>>>>>>> passthrough devices (though not from passthrough to emulated devices).
>>>>>>
>>>>>> Correct.
>>>>>>
>>>>>>>
>>>>>>> The conditions still seem kind of awkward to me, but I guess it makes
>>>>>>> sense.
>>>>>>
>>>>>> Is it the time to split this listener to RAM-listener and PCI bus listener?
>>>>>
>>>>> I'm not really sure what you mean by that.
>>>>>
>>>>>> On x86 it listens on the "memory" AS, on spapr - on the
>>>>>> "pci@800000020000000" AS, this will just create more confusion over time...
>>>>>
>>>>> Hm, it's still logically the same AS in each case - the PCI address
>>>>> space. It's just that in the x86 case that happens to be the same as
>>>>> the memory AS (at least when there isn't a guest side IOMMU).
>>>>
>>>> Hm. Ok.
>>>>
>>>>> I do wonder if that's really right even for x86 without IOMMU. The
>>>>> PCI address space is identity mapped to the "main" memory address
>>>>> space there, but I'm not sure it's mapped th *all* of the main memory
>>>>
>>>> What should have been in the place of "th" above? :)
>>>>
>>>>> address space, probably just certain ranges of it. That's what I was
>>>>> suggesting earlier in the thread.
>>>>
>>>> afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
>>>> anything like that. I am trying to figure out what is not correct with the
>>>> patch. Thanks,
>>>
>>> It is possible for x86 systems to have translation applied to MMIO vs
>>> RAM such that the processor view and device view of MMIO are different,
>>> putting them into separate address spaces, but this is not typical and
>>> not available on the class of chipsets that QEMU emulates for PC.
>>> Therefore I think it's correct that MMIO and RAM all live in one big
>>> happy, flat address space as they do now (assuming the guest IOMMU is
>>> not present or disabled). Thanks,
>>
>> Ah.. I think the thing I was missing is that on PC (at least with
>> typical chipsets) *all* MMIO essentially comes from PCI space. Even
>> the legacy devices are essentially ISA which is treated as being on a
>> bridge under the PCI space. On non-x86 there are often at least a
>> handful of MMIO devices that aren't within the PCI space - say, the
>> PCI host bridge itself at least. x86 avoids that by using the
>> separate IO space, which is also a bit weird in that it's
>> simultaneously direct attached to the cpu (and so doesn't need bridge
>> configuration), but also identified with the legay IO space treated as
>> being under two bridges (host->PCI, PCI->ISA) for other purposes.
>>
>> Maybe it's just me, but I find it makes more sense to me if I think of
>> it as the two ASes being equal because on PC the system address map
>> (address_space_memory) is made equal to the PCI address map, rather
>> than the PCI address map being made equal to the system one.
>
> It makes more sense to me too, we just do not exploit/expose this on SPAPR
> - the PCI address space only has 2xIOMMU and 1xMSI windows and that's it,
> no MMIO which is mapped to the system AS only (adding those to the PCI AS
> is little tricky as mentioned elsewhere).
>
> Anyway, I still wonder - what needs to be addressed in the 2/4 patch in
> order to proceed?
Ping?
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-26 8:36 ` Alexey Kardashevskiy
@ 2018-03-07 2:17 ` Alexey Kardashevskiy
2018-03-13 4:53 ` Alexey Kardashevskiy
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-03-07 2:17 UTC (permalink / raw)
To: David Gibson, Alex Williamson; +Cc: qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 8813 bytes --]
On 26/02/18 19:36, Alexey Kardashevskiy wrote:
> On 19/02/18 13:46, Alexey Kardashevskiy wrote:
>> On 16/02/18 16:28, David Gibson wrote:
>>> On Wed, Feb 14, 2018 at 08:55:41AM -0700, Alex Williamson wrote:
>>>> On Wed, 14 Feb 2018 19:09:16 +1100
>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>
>>>>> On 14/02/18 12:33, David Gibson wrote:
>>>>>> On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
>>>>>>> On 13/02/18 16:41, David Gibson wrote:
>>>>>>>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
>>>>>>>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>> On 13/02/18 03:06, Alex Williamson wrote:
>>>>>>>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
>>>>>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 12/02/18 16:19, David Gibson wrote:
>>>>>>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>>>>>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>>>>>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>>>>>>>>>>>> would not fail and so far this has been the case. A mapping failure
>>>>>>>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>>>>>>>>>>>> would not be mapped silently.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However we are going to change MSIX BAR handling so we will end having
>>>>>>>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>>>>>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
>>>>>>>>>>>>>> was just silently ignored, this checks the section alignment to
>>>>>>>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>>>>>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>>>>>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>>>>>>>>>>>> (aka "RAM device" regions).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>>>>>>>>>>>> could be used to avoid excessive error output.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is unlikely to cause any behavioral change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are some relatively superficial problems noted below.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But more fundamentally, this feels like it's extending an existing
>>>>>>>>>>>>> hack past the point of usefulness.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The explicit check for is_ram_device() here has always bothered me -
>>>>>>>>>>>>> it's not like a real bus bridge magically knows whether a target
>>>>>>>>>>>>> address maps to RAM or not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What I think is really going on is that even for systems without an
>>>>>>>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
>>>>>>>>>>>>> directly onto address_space_memory. Instead, there's a large, but
>>>>>>>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>>>>>>>>>>>> bus, which is identity mapped to the system bus. Details will vary
>>>>>>>>>>>>> with the system, but in practice we expect nothing but RAM to be in
>>>>>>>>>>>>> that window. Addresses not within that window won't be mapped to the
>>>>>>>>>>>>> system bus but will just be broadcast on the PCI bus and might be
>>>>>>>>>>>>> picked up as a p2p transaction.
>>>>>>>>>>>>
>>>>>>>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>>>>>>>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
>>>>>>>>>>>> does not.
>>>>>>>>>>>
>>>>>>>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
>>>>>>>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
>>>>>>>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
>>>>>>>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
>>>>>>>>>>> over any links. Thanks,
>>>>>>>>>>
>>>>>>>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
>>>>>>>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
>>>>>>>>>> and current that broadcast won't work for the passed through devices.
>>>>>>>>>
>>>>>>>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
>>>>>>>>> be translated through the IOMMU (and p2p from a passthrough to an
>>>>>>>>> emulated device is essentially impossible).
>>>>>>>>>
>>>>>>>>> But.. what does that have to do with this code. This is the memory
>>>>>>>>> area watcher, looking for memory regions being mapped directly into
>>>>>>>>> the PCI space. NOT IOMMU regions, since those are handled separately
>>>>>>>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
>>>>>>>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
>>>>>>>>
>>>>>>>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
>>>>>>>> the point here is that this will map RAM-like devices into the host
>>>>>>>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
>>>>>>>> passthrough devices (though not from passthrough to emulated devices).
>>>>>>>
>>>>>>> Correct.
>>>>>>>
>>>>>>>>
>>>>>>>> The conditions still seem kind of awkward to me, but I guess it makes
>>>>>>>> sense.
>>>>>>>
>>>>>>> Is it the time to split this listener to RAM-listener and PCI bus listener?
>>>>>>
>>>>>> I'm not really sure what you mean by that.
>>>>>>
>>>>>>> On x86 it listens on the "memory" AS, on spapr - on the
>>>>>>> "pci@800000020000000" AS, this will just create more confusion over time...
>>>>>>
>>>>>> Hm, it's still logically the same AS in each case - the PCI address
>>>>>> space. It's just that in the x86 case that happens to be the same as
>>>>>> the memory AS (at least when there isn't a guest side IOMMU).
>>>>>
>>>>> Hm. Ok.
>>>>>
>>>>>> I do wonder if that's really right even for x86 without IOMMU. The
>>>>>> PCI address space is identity mapped to the "main" memory address
>>>>>> space there, but I'm not sure it's mapped th *all* of the main memory
>>>>>
>>>>> What should have been in the place of "th" above? :)
>>>>>
>>>>>> address space, probably just certain ranges of it. That's what I was
>>>>>> suggesting earlier in the thread.
>>>>>
>>>>> afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
>>>>> anything like that. I am trying to figure out what is not correct with the
>>>>> patch. Thanks,
>>>>
>>>> It is possible for x86 systems to have translation applied to MMIO vs
>>>> RAM such that the processor view and device view of MMIO are different,
>>>> putting them into separate address spaces, but this is not typical and
>>>> not available on the class of chipsets that QEMU emulates for PC.
>>>> Therefore I think it's correct that MMIO and RAM all live in one big
>>>> happy, flat address space as they do now (assuming the guest IOMMU is
>>>> not present or disabled). Thanks,
>>>
>>> Ah.. I think the thing I was missing is that on PC (at least with
>>> typical chipsets) *all* MMIO essentially comes from PCI space. Even
>>> the legacy devices are essentially ISA which is treated as being on a
>>> bridge under the PCI space. On non-x86 there are often at least a
>>> handful of MMIO devices that aren't within the PCI space - say, the
>>> PCI host bridge itself at least. x86 avoids that by using the
>>> separate IO space, which is also a bit weird in that it's
>>> simultaneously direct attached to the cpu (and so doesn't need bridge
>>> configuration), but also identified with the legay IO space treated as
>>> being under two bridges (host->PCI, PCI->ISA) for other purposes.
>>>
>>> Maybe it's just me, but I find it makes more sense to me if I think of
>>> it as the two ASes being equal because on PC the system address map
>>> (address_space_memory) is made equal to the PCI address map, rather
>>> than the PCI address map being made equal to the system one.
>>
>> It makes more sense to me too, we just do not exploit/expose this on SPAPR
>> - the PCI address space only has 2xIOMMU and 1xMSI windows and that's it,
>> no MMIO which is mapped to the system AS only (adding those to the PCI AS
>> is little tricky as mentioned elsewhere).
>>
>> Anyway, I still wonder - what needs to be addressed in the 2/4 patch in
>> order to proceed?
>
> Ping?
>
Ping?
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-07 2:17 ` Alexey Kardashevskiy
@ 2018-03-13 4:53 ` Alexey Kardashevskiy
2018-03-13 16:56 ` Alex Williamson
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-03-13 4:53 UTC (permalink / raw)
To: David Gibson, Alex Williamson; +Cc: qemu-devel, qemu-ppc
On 7/3/18 1:17 pm, Alexey Kardashevskiy wrote:
> On 26/02/18 19:36, Alexey Kardashevskiy wrote:
>> On 19/02/18 13:46, Alexey Kardashevskiy wrote:
>>> On 16/02/18 16:28, David Gibson wrote:
>>>> On Wed, Feb 14, 2018 at 08:55:41AM -0700, Alex Williamson wrote:
>>>>> On Wed, 14 Feb 2018 19:09:16 +1100
>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>
>>>>>> On 14/02/18 12:33, David Gibson wrote:
>>>>>>> On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>> On 13/02/18 16:41, David Gibson wrote:
>>>>>>>>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
>>>>>>>>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>> On 13/02/18 03:06, Alex Williamson wrote:
>>>>>>>>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
>>>>>>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/02/18 16:19, David Gibson wrote:
>>>>>>>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>>>>>>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>>>>>>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>>>>>>>>>>>>> would not fail and so far this has been the case. A mapping failure
>>>>>>>>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>>>>>>>>>>>>> would not be mapped silently.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However we are going to change MSIX BAR handling so we will end having
>>>>>>>>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>>>>>>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
>>>>>>>>>>>>>>> was just silently ignored, this checks the section alignment to
>>>>>>>>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>>>>>>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>>>>>>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>>>>>>>>>>>>> (aka "RAM device" regions).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>>>>>>>>>>>>> could be used to avoid excessive error output.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is unlikely to cause any behavioral change.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There are some relatively superficial problems noted below.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But more fundamentally, this feels like it's extending an existing
>>>>>>>>>>>>>> hack past the point of usefulness.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The explicit check for is_ram_device() here has always bothered me -
>>>>>>>>>>>>>> it's not like a real bus bridge magically knows whether a target
>>>>>>>>>>>>>> address maps to RAM or not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What I think is really going on is that even for systems without an
>>>>>>>>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
>>>>>>>>>>>>>> directly onto address_space_memory. Instead, there's a large, but
>>>>>>>>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>>>>>>>>>>>>> bus, which is identity mapped to the system bus. Details will vary
>>>>>>>>>>>>>> with the system, but in practice we expect nothing but RAM to be in
>>>>>>>>>>>>>> that window. Addresses not within that window won't be mapped to the
>>>>>>>>>>>>>> system bus but will just be broadcast on the PCI bus and might be
>>>>>>>>>>>>>> picked up as a p2p transaction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>>>>>>>>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
>>>>>>>>>>>>> does not.
>>>>>>>>>>>>
>>>>>>>>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
>>>>>>>>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
>>>>>>>>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
>>>>>>>>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
>>>>>>>>>>>> over any links. Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
>>>>>>>>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
>>>>>>>>>>> and current that broadcast won't work for the passed through devices.
>>>>>>>>>>
>>>>>>>>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
>>>>>>>>>> be translated through the IOMMU (and p2p from a passthrough to an
>>>>>>>>>> emulated device is essentially impossible).
>>>>>>>>>>
>>>>>>>>>> But.. what does that have to do with this code. This is the memory
>>>>>>>>>> area watcher, looking for memory regions being mapped directly into
>>>>>>>>>> the PCI space. NOT IOMMU regions, since those are handled separately
>>>>>>>>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
>>>>>>>>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
>>>>>>>>>
>>>>>>>>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
>>>>>>>>> the point here is that this will map RAM-like devices into the host
>>>>>>>>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
>>>>>>>>> passthrough devices (though not from passthrough to emulated devices).
>>>>>>>>
>>>>>>>> Correct.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The conditions still seem kind of awkward to me, but I guess it makes
>>>>>>>>> sense.
>>>>>>>>
>>>>>>>> Is it the time to split this listener to RAM-listener and PCI bus listener?
>>>>>>>
>>>>>>> I'm not really sure what you mean by that.
>>>>>>>
>>>>>>>> On x86 it listens on the "memory" AS, on spapr - on the
>>>>>>>> "pci@800000020000000" AS, this will just create more confusion over time...
>>>>>>>
>>>>>>> Hm, it's still logically the same AS in each case - the PCI address
>>>>>>> space. It's just that in the x86 case that happens to be the same as
>>>>>>> the memory AS (at least when there isn't a guest side IOMMU).
>>>>>>
>>>>>> Hm. Ok.
>>>>>>
>>>>>>> I do wonder if that's really right even for x86 without IOMMU. The
>>>>>>> PCI address space is identity mapped to the "main" memory address
>>>>>>> space there, but I'm not sure it's mapped th *all* of the main memory
>>>>>>
>>>>>> What should have been in the place of "th" above? :)
>>>>>>
>>>>>>> address space, probably just certain ranges of it. That's what I was
>>>>>>> suggesting earlier in the thread.
>>>>>>
>>>>>> afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
>>>>>> anything like that. I am trying to figure out what is not correct with the
>>>>>> patch. Thanks,
>>>>>
>>>>> It is possible for x86 systems to have translation applied to MMIO vs
>>>>> RAM such that the processor view and device view of MMIO are different,
>>>>> putting them into separate address spaces, but this is not typical and
>>>>> not available on the class of chipsets that QEMU emulates for PC.
>>>>> Therefore I think it's correct that MMIO and RAM all live in one big
>>>>> happy, flat address space as they do now (assuming the guest IOMMU is
>>>>> not present or disabled). Thanks,
>>>>
>>>> Ah.. I think the thing I was missing is that on PC (at least with
>>>> typical chipsets) *all* MMIO essentially comes from PCI space. Even
>>>> the legacy devices are essentially ISA which is treated as being on a
>>>> bridge under the PCI space. On non-x86 there are often at least a
>>>> handful of MMIO devices that aren't within the PCI space - say, the
>>>> PCI host bridge itself at least. x86 avoids that by using the
>>>> separate IO space, which is also a bit weird in that it's
>>>> simultaneously direct attached to the cpu (and so doesn't need bridge
>>>> configuration), but also identified with the legay IO space treated as
>>>> being under two bridges (host->PCI, PCI->ISA) for other purposes.
>>>>
>>>> Maybe it's just me, but I find it makes more sense to me if I think of
>>>> it as the two ASes being equal because on PC the system address map
>>>> (address_space_memory) is made equal to the PCI address map, rather
>>>> than the PCI address map being made equal to the system one.
>>>
>>> It makes more sense to me too, we just do not exploit/expose this on SPAPR
>>> - the PCI address space only has 2xIOMMU and 1xMSI windows and that's it,
>>> no MMIO which is mapped to the system AS only (adding those to the PCI AS
>>> is little tricky as mentioned elsewhere).
>>>
>>> Anyway, I still wonder - what needs to be addressed in the 2/4 patch in
>>> order to proceed?
>>
>> Ping?
>>
>
>
> Ping?
>
>
Could anyone please enlighten me what needs to be done with this patchset
to proceed, or confirm that it is ok but not going anywhere as everybody is
busy with other things? :) Thanks,
--
Alexey
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-13 4:53 ` Alexey Kardashevskiy
@ 2018-03-13 16:56 ` Alex Williamson
2018-03-13 17:13 ` Auger Eric
2018-03-14 2:40 ` Alexey Kardashevskiy
0 siblings, 2 replies; 34+ messages in thread
From: Alex Williamson @ 2018-03-13 16:56 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: David Gibson, qemu-devel, qemu-ppc, Auger Eric
[Cc +Eric]
On Tue, 13 Mar 2018 15:53:19 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 7/3/18 1:17 pm, Alexey Kardashevskiy wrote:
> > On 26/02/18 19:36, Alexey Kardashevskiy wrote:
> >> On 19/02/18 13:46, Alexey Kardashevskiy wrote:
> >>> On 16/02/18 16:28, David Gibson wrote:
> >>>> On Wed, Feb 14, 2018 at 08:55:41AM -0700, Alex Williamson wrote:
> >>>>> On Wed, 14 Feb 2018 19:09:16 +1100
> >>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >>>>>
> >>>>>> On 14/02/18 12:33, David Gibson wrote:
> >>>>>>> On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
> >>>>>>>> On 13/02/18 16:41, David Gibson wrote:
> >>>>>>>>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
> >>>>>>>>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
> >>>>>>>>>>> On 13/02/18 03:06, Alex Williamson wrote:
> >>>>>>>>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
> >>>>>>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 12/02/18 16:19, David Gibson wrote:
> >>>>>>>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
> >>>>>>>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
> >>>>>>>>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
> >>>>>>>>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
> >>>>>>>>>>>>>>> would not fail and so far this has been the case. A mapping failure
> >>>>>>>>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
> >>>>>>>>>>>>>>> would not be mapped silently.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> However we are going to change MSIX BAR handling so we will end having
> >>>>>>>>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
> >>>>>>>>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
> >>>>>>>>>>>>>>> was just silently ignored, this checks the section alignment to
> >>>>>>>>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
> >>>>>>>>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
> >>>>>>>>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
> >>>>>>>>>>>>>>> (aka "RAM device" regions).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
> >>>>>>>>>>>>>>> could be used to avoid excessive error output.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is unlikely to cause any behavioral change.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> There are some relatively superficial problems noted below.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> But more fundamentally, this feels like it's extending an existing
> >>>>>>>>>>>>>> hack past the point of usefulness.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The explicit check for is_ram_device() here has always bothered me -
> >>>>>>>>>>>>>> it's not like a real bus bridge magically knows whether a target
> >>>>>>>>>>>>>> address maps to RAM or not.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> What I think is really going on is that even for systems without an
> >>>>>>>>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
> >>>>>>>>>>>>>> directly onto address_space_memory. Instead, there's a large, but
> >>>>>>>>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
> >>>>>>>>>>>>>> bus, which is identity mapped to the system bus. Details will vary
> >>>>>>>>>>>>>> with the system, but in practice we expect nothing but RAM to be in
> >>>>>>>>>>>>>> that window. Addresses not within that window won't be mapped to the
> >>>>>>>>>>>>>> system bus but will just be broadcast on the PCI bus and might be
> >>>>>>>>>>>>>> picked up as a p2p transaction.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
> >>>>>>>>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
> >>>>>>>>>>>>> does not.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
> >>>>>>>>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
> >>>>>>>>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
> >>>>>>>>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
> >>>>>>>>>>>> over any links. Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
> >>>>>>>>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
> >>>>>>>>>>> and current that broadcast won't work for the passed through devices.
> >>>>>>>>>>
> >>>>>>>>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
> >>>>>>>>>> be translated through the IOMMU (and p2p from a passthrough to an
> >>>>>>>>>> emulated device is essentially impossible).
> >>>>>>>>>>
> >>>>>>>>>> But.. what does that have to do with this code. This is the memory
> >>>>>>>>>> area watcher, looking for memory regions being mapped directly into
> >>>>>>>>>> the PCI space. NOT IOMMU regions, since those are handled separately
> >>>>>>>>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
> >>>>>>>>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
> >>>>>>>>>
> >>>>>>>>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
> >>>>>>>>> the point here is that this will map RAM-like devices into the host
> >>>>>>>>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
> >>>>>>>>> passthrough devices (though not from passthrough to emulated devices).
> >>>>>>>>
> >>>>>>>> Correct.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The conditions still seem kind of awkward to me, but I guess it makes
> >>>>>>>>> sense.
> >>>>>>>>
> >>>>>>>> Is it the time to split this listener to RAM-listener and PCI bus listener?
> >>>>>>>
> >>>>>>> I'm not really sure what you mean by that.
> >>>>>>>
> >>>>>>>> On x86 it listens on the "memory" AS, on spapr - on the
> >>>>>>>> "pci@800000020000000" AS, this will just create more confusion over time...
> >>>>>>>
> >>>>>>> Hm, it's still logically the same AS in each case - the PCI address
> >>>>>>> space. It's just that in the x86 case that happens to be the same as
> >>>>>>> the memory AS (at least when there isn't a guest side IOMMU).
> >>>>>>
> >>>>>> Hm. Ok.
> >>>>>>
> >>>>>>> I do wonder if that's really right even for x86 without IOMMU. The
> >>>>>>> PCI address space is identity mapped to the "main" memory address
> >>>>>>> space there, but I'm not sure it's mapped th *all* of the main memory
> >>>>>>
> >>>>>> What should have been in the place of "th" above? :)
> >>>>>>
> >>>>>>> address space, probably just certain ranges of it. That's what I was
> >>>>>>> suggesting earlier in the thread.
> >>>>>>
> >>>>>> afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
> >>>>>> anything like that. I am trying to figure out what is not correct with the
> >>>>>> patch. Thanks,
> >>>>>
> >>>>> It is possible for x86 systems to have translation applied to MMIO vs
> >>>>> RAM such that the processor view and device view of MMIO are different,
> >>>>> putting them into separate address spaces, but this is not typical and
> >>>>> not available on the class of chipsets that QEMU emulates for PC.
> >>>>> Therefore I think it's correct that MMIO and RAM all live in one big
> >>>>> happy, flat address space as they do now (assuming the guest IOMMU is
> >>>>> not present or disabled). Thanks,
> >>>>
> >>>> Ah.. I think the thing I was missing is that on PC (at least with
> >>>> typical chipsets) *all* MMIO essentially comes from PCI space. Even
> >>>> the legacy devices are essentially ISA which is treated as being on a
> >>>> bridge under the PCI space. On non-x86 there are often at least a
> >>>> handful of MMIO devices that aren't within the PCI space - say, the
> >>>> PCI host bridge itself at least. x86 avoids that by using the
> >>>> separate IO space, which is also a bit weird in that it's
> >>>> simultaneously direct attached to the cpu (and so doesn't need bridge
> >>>> configuration), but also identified with the legay IO space treated as
> >>>> being under two bridges (host->PCI, PCI->ISA) for other purposes.
> >>>>
> >>>> Maybe it's just me, but I find it makes more sense to me if I think of
> >>>> it as the two ASes being equal because on PC the system address map
> >>>> (address_space_memory) is made equal to the PCI address map, rather
> >>>> than the PCI address map being made equal to the system one.
> >>>
> >>> It makes more sense to me too, we just do not exploit/expose this on SPAPR
> >>> - the PCI address space only has 2xIOMMU and 1xMSI windows and that's it,
> >>> no MMIO which is mapped to the system AS only (adding those to the PCI AS
> >>> is little tricky as mentioned elsewhere).
> >>>
> >>> Anyway, I still wonder - what needs to be addressed in the 2/4 patch in
> >>> order to proceed?
> >>
> >> Ping?
> >>
> >
> >
> > Ping?
> >
> >
>
>
> Could anyone please enlighten me what needs to be done with this patchset
> to proceed, or confirm that it is ok but not going anywhere as everybody is
> busy with other things? :) Thanks,
Actually making sure it compiles would have been nice:
qemu.git/hw/vfio/common.c: In function ‘vfio_listener_region_add’:
qemu.git/hw/vfio/common.c:550:40: error: invalid operands to binary & (have ‘Int128 {aka struct Int128}’ and ‘hwaddr {aka long long unsigned int}’)
if ((iova & pgmask) || (llsize & pgmask)) {
^
qemu.git/hw/vfio/common.c: In function ‘vfio_listener_region_del’:
qemu.git/hw/vfio/common.c:669:50: error: invalid operands to binary & (have ‘Int128 {aka struct Int128}’ and ‘hwaddr {aka long long unsigned int}’)
try_unmap = !((iova & pgmask) || (llsize & pgmask));
^
Clearly llsize needs to be wrapped in int128_get64() here. Should I
presume that testing of this patch is equally lacking? Eric, have you
done any testing of this? I think this was fixing a mapping issue you
reported. Thanks,
Alex
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-13 16:56 ` Alex Williamson
@ 2018-03-13 17:13 ` Auger Eric
2018-03-13 19:17 ` Eric Blake
2018-03-14 2:40 ` Alexey Kardashevskiy
1 sibling, 1 reply; 34+ messages in thread
From: Auger Eric @ 2018-03-13 17:13 UTC (permalink / raw)
To: Alex Williamson, Alexey Kardashevskiy; +Cc: David Gibson, qemu-devel, qemu-ppc
Hi Alex,
On 13/03/18 17:56, Alex Williamson wrote:
> [Cc +Eric]
>
> On Tue, 13 Mar 2018 15:53:19 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
>> On 7/3/18 1:17 pm, Alexey Kardashevskiy wrote:
>>> On 26/02/18 19:36, Alexey Kardashevskiy wrote:
>>>> On 19/02/18 13:46, Alexey Kardashevskiy wrote:
>>>>> On 16/02/18 16:28, David Gibson wrote:
>>>>>> On Wed, Feb 14, 2018 at 08:55:41AM -0700, Alex Williamson wrote:
>>>>>>> On Wed, 14 Feb 2018 19:09:16 +1100
>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>
>>>>>>>> On 14/02/18 12:33, David Gibson wrote:
>>>>>>>>> On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>> On 13/02/18 16:41, David Gibson wrote:
>>>>>>>>>>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
>>>>>>>>>>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>>> On 13/02/18 03:06, Alex Williamson wrote:
>>>>>>>>>>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
>>>>>>>>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 12/02/18 16:19, David Gibson wrote:
>>>>>>>>>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>>>>>>>>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>>>>>>>>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>>>>>>>>>>>>>>> would not fail and so far this has been the case. A mapping failure
>>>>>>>>>>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>>>>>>>>>>>>>>> would not be mapped silently.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However we are going to change MSIX BAR handling so we will end having
>>>>>>>>>>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>>>>>>>>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
>>>>>>>>>>>>>>>>> was just silently ignored, this checks the section alignment to
>>>>>>>>>>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>>>>>>>>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>>>>>>>>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>>>>>>>>>>>>>>> (aka "RAM device" regions).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>>>>>>>>>>>>>>> could be used to avoid excessive error output.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is unlikely to cause any behavioral change.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There are some relatively superficial problems noted below.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But more fundamentally, this feels like it's extending an existing
>>>>>>>>>>>>>>>> hack past the point of usefulness.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The explicit check for is_ram_device() here has always bothered me -
>>>>>>>>>>>>>>>> it's not like a real bus bridge magically knows whether a target
>>>>>>>>>>>>>>>> address maps to RAM or not.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What I think is really going on is that even for systems without an
>>>>>>>>>>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
>>>>>>>>>>>>>>>> directly onto address_space_memory. Instead, there's a large, but
>>>>>>>>>>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>>>>>>>>>>>>>>> bus, which is identity mapped to the system bus. Details will vary
>>>>>>>>>>>>>>>> with the system, but in practice we expect nothing but RAM to be in
>>>>>>>>>>>>>>>> that window. Addresses not within that window won't be mapped to the
>>>>>>>>>>>>>>>> system bus but will just be broadcast on the PCI bus and might be
>>>>>>>>>>>>>>>> picked up as a p2p transaction.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>>>>>>>>>>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
>>>>>>>>>>>>>>> does not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
>>>>>>>>>>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
>>>>>>>>>>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
>>>>>>>>>>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
>>>>>>>>>>>>>> over any links. Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
>>>>>>>>>>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
>>>>>>>>>>>>> and current that broadcast won't work for the passed through devices.
>>>>>>>>>>>>
>>>>>>>>>>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
>>>>>>>>>>>> be translated through the IOMMU (and p2p from a passthrough to an
>>>>>>>>>>>> emulated device is essentially impossible).
>>>>>>>>>>>>
>>>>>>>>>>>> But.. what does that have to do with this code. This is the memory
>>>>>>>>>>>> area watcher, looking for memory regions being mapped directly into
>>>>>>>>>>>> the PCI space. NOT IOMMU regions, since those are handled separately
>>>>>>>>>>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
>>>>>>>>>>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
>>>>>>>>>>>
>>>>>>>>>>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
>>>>>>>>>>> the point here is that this will map RAM-like devices into the host
>>>>>>>>>>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
>>>>>>>>>>> passthrough devices (though not from passthrough to emulated devices).
>>>>>>>>>>
>>>>>>>>>> Correct.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The conditions still seem kind of awkward to me, but I guess it makes
>>>>>>>>>>> sense.
>>>>>>>>>>
>>>>>>>>>> Is it the time to split this listener to RAM-listener and PCI bus listener?
>>>>>>>>>
>>>>>>>>> I'm not really sure what you mean by that.
>>>>>>>>>
>>>>>>>>>> On x86 it listens on the "memory" AS, on spapr - on the
>>>>>>>>>> "pci@800000020000000" AS, this will just create more confusion over time...
>>>>>>>>>
>>>>>>>>> Hm, it's still logically the same AS in each case - the PCI address
>>>>>>>>> space. It's just that in the x86 case that happens to be the same as
>>>>>>>>> the memory AS (at least when there isn't a guest side IOMMU).
>>>>>>>>
>>>>>>>> Hm. Ok.
>>>>>>>>
>>>>>>>>> I do wonder if that's really right even for x86 without IOMMU. The
>>>>>>>>> PCI address space is identity mapped to the "main" memory address
>>>>>>>>> space there, but I'm not sure it's mapped th *all* of the main memory
>>>>>>>>
>>>>>>>> What should have been in the place of "th" above? :)
>>>>>>>>
>>>>>>>>> address space, probably just certain ranges of it. That's what I was
>>>>>>>>> suggesting earlier in the thread.
>>>>>>>>
>>>>>>>> afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
>>>>>>>> anything like that. I am trying to figure out what is not correct with the
>>>>>>>> patch. Thanks,
>>>>>>>
>>>>>>> It is possible for x86 systems to have translation applied to MMIO vs
>>>>>>> RAM such that the processor view and device view of MMIO are different,
>>>>>>> putting them into separate address spaces, but this is not typical and
>>>>>>> not available on the class of chipsets that QEMU emulates for PC.
>>>>>>> Therefore I think it's correct that MMIO and RAM all live in one big
>>>>>>> happy, flat address space as they do now (assuming the guest IOMMU is
>>>>>>> not present or disabled). Thanks,
>>>>>>
>>>>>> Ah.. I think the thing I was missing is that on PC (at least with
>>>>>> typical chipsets) *all* MMIO essentially comes from PCI space. Even
>>>>>> the legacy devices are essentially ISA which is treated as being on a
>>>>>> bridge under the PCI space. On non-x86 there are often at least a
>>>>>> handful of MMIO devices that aren't within the PCI space - say, the
>>>>>> PCI host bridge itself at least. x86 avoids that by using the
>>>>>> separate IO space, which is also a bit weird in that it's
>>>>>> simultaneously direct attached to the cpu (and so doesn't need bridge
>>>>>> configuration), but also identified with the legay IO space treated as
>>>>>> being under two bridges (host->PCI, PCI->ISA) for other purposes.
>>>>>>
>>>>>> Maybe it's just me, but I find it makes more sense to me if I think of
>>>>>> it as the two ASes being equal because on PC the system address map
>>>>>> (address_space_memory) is made equal to the PCI address map, rather
>>>>>> than the PCI address map being made equal to the system one.
>>>>>
>>>>> It makes more sense to me too, we just do not exploit/expose this on SPAPR
>>>>> - the PCI address space only has 2xIOMMU and 1xMSI windows and that's it,
>>>>> no MMIO which is mapped to the system AS only (adding those to the PCI AS
>>>>> is little tricky as mentioned elsewhere).
>>>>>
>>>>> Anyway, I still wonder - what needs to be addressed in the 2/4 patch in
>>>>> order to proceed?
>>>>
>>>> Ping?
>>>>
>>>
>>>
>>> Ping?
>>>
>>>
>>
>>
>> Could anyone please enlighten me what needs to be done with this patchset
>> to proceed, or confirm that it is ok but not going anywhere as everybody is
>> busy with other things? :) Thanks,
>
> Actually making sure it compiles would have been nice:
>
> qemu.git/hw/vfio/common.c: In function ‘vfio_listener_region_add’:
> qemu.git/hw/vfio/common.c:550:40: error: invalid operands to binary & (have ‘Int128 {aka struct Int128}’ and ‘hwaddr {aka long long unsigned int}’)
> if ((iova & pgmask) || (llsize & pgmask)) {
> ^
> qemu.git/hw/vfio/common.c: In function ‘vfio_listener_region_del’:
> qemu.git/hw/vfio/common.c:669:50: error: invalid operands to binary & (have ‘Int128 {aka struct Int128}’ and ‘hwaddr {aka long long unsigned int}’)
> try_unmap = !((iova & pgmask) || (llsize & pgmask));
> ^
> Clearly llsize needs to be wrapped in int128_get64() here. Should I
> presume that testing of this patch is equally lacking? Eric, have you
> done any testing of this? I think this was fixing a mapping issue you
> reported. Thanks,
not that version unfortunately. I don't have access to the HW on which I
had the issue anymore. Maybe I could by the beg of next week?
Thanks
Eric
>
> Alex
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-13 17:13 ` Auger Eric
@ 2018-03-13 19:17 ` Eric Blake
0 siblings, 0 replies; 34+ messages in thread
From: Eric Blake @ 2018-03-13 19:17 UTC (permalink / raw)
To: Auger Eric, Alex Williamson, Alexey Kardashevskiy
Cc: qemu-ppc, qemu-devel, David Gibson
[Making a meta-comment that I've pointed out to others before]
On 03/13/2018 12:13 PM, Auger Eric wrote:
> Hi Alex,
...
>>>>>>>>>>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
17 levels of '>' before I even began my reply. And several screenfuls
of content that I'm snipping...
>> Clearly llsize needs to be wrapped in int128_get64() here. Should I
>> presume that testing of this patch is equally lacking? Eric, have you
>> done any testing of this? I think this was fixing a mapping issue you
>> reported. Thanks,
> not that version unfortunately. I don't have access to the HW on which I
> had the issue anymore. Maybe I could by the beg of next week?
before getting to the 2-line meat of the message. It's okay to snip
portions of the quoted content that are no longer relevant to the
immediate message, as it helps improve the signal-to-noise ratio (we
have list archives, for when referring to prior context is needed)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-13 16:56 ` Alex Williamson
2018-03-13 17:13 ` Auger Eric
@ 2018-03-14 2:40 ` Alexey Kardashevskiy
2018-03-15 2:36 ` Alex Williamson
1 sibling, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-03-14 2:40 UTC (permalink / raw)
To: Alex Williamson; +Cc: David Gibson, qemu-devel, qemu-ppc, Auger Eric
On 14/3/18 3:56 am, Alex Williamson wrote:
> [Cc +Eric]
>
> On Tue, 13 Mar 2018 15:53:19 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
>> On 7/3/18 1:17 pm, Alexey Kardashevskiy wrote:
>>> On 26/02/18 19:36, Alexey Kardashevskiy wrote:
>>>> On 19/02/18 13:46, Alexey Kardashevskiy wrote:
>>>>> On 16/02/18 16:28, David Gibson wrote:
>>>>>> On Wed, Feb 14, 2018 at 08:55:41AM -0700, Alex Williamson wrote:
>>>>>>> On Wed, 14 Feb 2018 19:09:16 +1100
>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>
>>>>>>>> On 14/02/18 12:33, David Gibson wrote:
>>>>>>>>> On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>> On 13/02/18 16:41, David Gibson wrote:
>>>>>>>>>>> On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
>>>>>>>>>>>> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>>> On 13/02/18 03:06, Alex Williamson wrote:
>>>>>>>>>>>>>> On Mon, 12 Feb 2018 18:05:54 +1100
>>>>>>>>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 12/02/18 16:19, David Gibson wrote:
>>>>>>>>>>>>>>>> On Fri, Feb 09, 2018 at 06:55:01PM +1100, Alexey Kardashevskiy wrote:
>>>>>>>>>>>>>>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>>>>>>>>>>>>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>>>>>>>>>>>>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>>>>>>>>>>>>>>> would not fail and so far this has been the case. A mapping failure
>>>>>>>>>>>>>>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>>>>>>>>>>>>>>> would not be mapped silently.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However we are going to change MSIX BAR handling so we will end having
>>>>>>>>>>>>>>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>>>>>>>>>>>>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In order to avoid fatal failures on what previously was not a failure and
>>>>>>>>>>>>>>>>> was just silently ignored, this checks the section alignment to
>>>>>>>>>>>>>>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>>>>>>>>>>>>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>>>>>>>>>>>>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>>>>>>>>>>>>>>> (aka "RAM device" regions).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>>>>>>>>>>>>>>> could be used to avoid excessive error output.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is unlikely to cause any behavioral change.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There are some relatively superficial problems noted below.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But more fundamentally, this feels like it's extending an existing
>>>>>>>>>>>>>>>> hack past the point of usefulness.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The explicit check for is_ram_device() here has always bothered me -
>>>>>>>>>>>>>>>> it's not like a real bus bridge magically knows whether a target
>>>>>>>>>>>>>>>> address maps to RAM or not.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What I think is really going on is that even for systems without an
>>>>>>>>>>>>>>>> IOMMU, it's not really true to say that the PCI address space maps
>>>>>>>>>>>>>>>> directly onto address_space_memory. Instead, there's a large, but
>>>>>>>>>>>>>>>> much less than 2^64 sized, "upstream window" at address 0 on the PCI
>>>>>>>>>>>>>>>> bus, which is identity mapped to the system bus. Details will vary
>>>>>>>>>>>>>>>> with the system, but in practice we expect nothing but RAM to be in
>>>>>>>>>>>>>>>> that window. Addresses not within that window won't be mapped to the
>>>>>>>>>>>>>>>> system bus but will just be broadcast on the PCI bus and might be
>>>>>>>>>>>>>>>> picked up as a p2p transaction.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently this p2p works only via the IOMMU, direct p2p is not possible as
>>>>>>>>>>>>>>> the guest needs to know physical MMIO addresses to make p2p work and it
>>>>>>>>>>>>>>> does not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /me points to the Direct Translated P2P section of the ACS spec, though
>>>>>>>>>>>>>> it's as prone to spoofing by the device as ATS. In any case, p2p
>>>>>>>>>>>>>> reflected from the IOMMU is still p2p and offloads the CPU even if
>>>>>>>>>>>>>> bandwidth suffers vs bare metal depending on if the data doubles back
>>>>>>>>>>>>>> over any links. Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure, I was just saying that p2p via IOMMU won't be as simple as broadcast
>>>>>>>>>>>>> on the PCI bus, IOMMU needs to be programmed in advance to make this work,
>>>>>>>>>>>>> and current that broadcast won't work for the passed through devices.
>>>>>>>>>>>>
>>>>>>>>>>>> Well, sure, p2p in a guest with passthrough devices clearly needs to
>>>>>>>>>>>> be translated through the IOMMU (and p2p from a passthrough to an
>>>>>>>>>>>> emulated device is essentially impossible).
>>>>>>>>>>>>
>>>>>>>>>>>> But.. what does that have to do with this code. This is the memory
>>>>>>>>>>>> area watcher, looking for memory regions being mapped directly into
>>>>>>>>>>>> the PCI space. NOT IOMMU regions, since those are handled separately
>>>>>>>>>>>> by wiring up the IOMMU notifier. This will only trigger if RAM-like,
>>>>>>>>>>>> non-RAM regions are put into PCI space *not* behind an IOMMMU.
>>>>>>>>>>>
>>>>>>>>>>> Duh, sorry, realised I was mixing up host and guest IOMMU. I guess
>>>>>>>>>>> the point here is that this will map RAM-like devices into the host
>>>>>>>>>>> IOMMU when there is no guest IOMMU, allowing p2p transactions between
>>>>>>>>>>> passthrough devices (though not from passthrough to emulated devices).
>>>>>>>>>>
>>>>>>>>>> Correct.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The conditions still seem kind of awkward to me, but I guess it makes
>>>>>>>>>>> sense.
>>>>>>>>>>
>>>>>>>>>> Is it the time to split this listener to RAM-listener and PCI bus listener?
>>>>>>>>>
>>>>>>>>> I'm not really sure what you mean by that.
>>>>>>>>>
>>>>>>>>>> On x86 it listens on the "memory" AS, on spapr - on the
>>>>>>>>>> "pci@800000020000000" AS, this will just create more confusion over time...
>>>>>>>>>
>>>>>>>>> Hm, it's still logically the same AS in each case - the PCI address
>>>>>>>>> space. It's just that in the x86 case that happens to be the same as
>>>>>>>>> the memory AS (at least when there isn't a guest side IOMMU).
>>>>>>>>
>>>>>>>> Hm. Ok.
>>>>>>>>
>>>>>>>>> I do wonder if that's really right even for x86 without IOMMU. The
>>>>>>>>> PCI address space is identity mapped to the "main" memory address
>>>>>>>>> space there, but I'm not sure it's mapped th *all* of the main memory
>>>>>>>>
>>>>>>>> What should have been in the place of "th" above? :)
>>>>>>>>
>>>>>>>>> address space, probably just certain ranges of it. That's what I was
>>>>>>>>> suggesting earlier in the thread.
>>>>>>>>
>>>>>>>> afaict vfio is trying to mmap every RAM MR == KVM memory slot, no ranges or
>>>>>>>> anything like that. I am trying to figure out what is not correct with the
>>>>>>>> patch. Thanks,
>>>>>>>
>>>>>>> It is possible for x86 systems to have translation applied to MMIO vs
>>>>>>> RAM such that the processor view and device view of MMIO are different,
>>>>>>> putting them into separate address spaces, but this is not typical and
>>>>>>> not available on the class of chipsets that QEMU emulates for PC.
>>>>>>> Therefore I think it's correct that MMIO and RAM all live in one big
>>>>>>> happy, flat address space as they do now (assuming the guest IOMMU is
>>>>>>> not present or disabled). Thanks,
>>>>>>
>>>>>> Ah.. I think the thing I was missing is that on PC (at least with
>>>>>> typical chipsets) *all* MMIO essentially comes from PCI space. Even
>>>>>> the legacy devices are essentially ISA which is treated as being on a
>>>>>> bridge under the PCI space. On non-x86 there are often at least a
>>>>>> handful of MMIO devices that aren't within the PCI space - say, the
>>>>>> PCI host bridge itself at least. x86 avoids that by using the
>>>>>> separate IO space, which is also a bit weird in that it's
>>>>>> simultaneously direct attached to the cpu (and so doesn't need bridge
>>>>>> configuration), but also identified with the legay IO space treated as
>>>>>> being under two bridges (host->PCI, PCI->ISA) for other purposes.
>>>>>>
>>>>>> Maybe it's just me, but I find it makes more sense to me if I think of
>>>>>> it as the two ASes being equal because on PC the system address map
>>>>>> (address_space_memory) is made equal to the PCI address map, rather
>>>>>> than the PCI address map being made equal to the system one.
>>>>>
>>>>> It makes more sense to me too, we just do not exploit/expose this on SPAPR
>>>>> - the PCI address space only has 2xIOMMU and 1xMSI windows and that's it,
>>>>> no MMIO which is mapped to the system AS only (adding those to the PCI AS
>>>>> is little tricky as mentioned elsewhere).
>>>>>
>>>>> Anyway, I still wonder - what needs to be addressed in the 2/4 patch in
>>>>> order to proceed?
>>>>
>>>> Ping?
>>>>
>>>
>>>
>>> Ping?
>>>
>>>
>>
>>
>> Could anyone please enlighten me what needs to be done with this patchset
>> to proceed, or confirm that it is ok but not going anywhere as everybody is
>> busy with other things? :) Thanks,
>
> Actually making sure it compiles would have been nice:
>
> qemu.git/hw/vfio/common.c: In function ‘vfio_listener_region_add’:
> qemu.git/hw/vfio/common.c:550:40: error: invalid operands to binary & (have ‘Int128 {aka struct Int128}’ and ‘hwaddr {aka long long unsigned int}’)
> if ((iova & pgmask) || (llsize & pgmask)) {
> ^
> qemu.git/hw/vfio/common.c: In function ‘vfio_listener_region_del’:
> qemu.git/hw/vfio/common.c:669:50: error: invalid operands to binary & (have ‘Int128 {aka struct Int128}’ and ‘hwaddr {aka long long unsigned int}’)
> try_unmap = !((iova & pgmask) || (llsize & pgmask));
> ^
> Clearly llsize needs to be wrapped in int128_get64() here. Should I
> presume that testing of this patch is equally lacking?
No.
I do not know how but this definitely compiles for me with these:
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
I always thought Int128 is a struct but it turns out there are __uint128_t
and __int128_t and everywhere I compile (including x86_64 laptop) there is
CONFIG_INT128=y in config-host.mak, hence no error.
I can see that you fixed it (thanks for that!) but how do you compile it to
get this error? There is no way to disable gcc's types and even 4.8.5 can
do these. Thanks,
> Eric, have you
> done any testing of this? I think this was fixing a mapping issue you
> reported. Thanks,
>
> Alex
>
--
Alexey
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-14 2:40 ` Alexey Kardashevskiy
@ 2018-03-15 2:36 ` Alex Williamson
0 siblings, 0 replies; 34+ messages in thread
From: Alex Williamson @ 2018-03-15 2:36 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Auger Eric, qemu-ppc, qemu-devel, David Gibson
On Wed, 14 Mar 2018 13:40:21 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 14/3/18 3:56 am, Alex Williamson wrote:
> > Actually making sure it compiles would have been nice:
> >
> > qemu.git/hw/vfio/common.c: In function ‘vfio_listener_region_add’:
> > qemu.git/hw/vfio/common.c:550:40: error: invalid operands to binary & (have ‘Int128 {aka struct Int128}’ and ‘hwaddr {aka long long unsigned int}’)
> > if ((iova & pgmask) || (llsize & pgmask)) {
> > ^
> > qemu.git/hw/vfio/common.c: In function ‘vfio_listener_region_del’:
> > qemu.git/hw/vfio/common.c:669:50: error: invalid operands to binary & (have ‘Int128 {aka struct Int128}’ and ‘hwaddr {aka long long unsigned int}’)
> > try_unmap = !((iova & pgmask) || (llsize & pgmask));
> > ^
> > Clearly llsize needs to be wrapped in int128_get64() here. Should I
> > presume that testing of this patch is equally lacking?
>
> No.
>
> I do not know how but this definitely compiles for me with these:
>
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
> gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
>
> I always thought Int128 is a struct but it turns out there are __uint128_t
> and __int128_t and everywhere I compile (including x86_64 laptop) there is
> CONFIG_INT128=y in config-host.mak, hence no error.
>
> I can see that you fixed it (thanks for that!) but how do you compile it to
> get this error? There is no way to disable gcc's types and even 4.8.5 can
> do these. Thanks,
Hmm, I always try to do a 32bit build before I send a pull request,
that's where I started this time. I thought an Int128 was always a
structure, so I figured it always failed. Good to know there was more
than just my testing on this commit. Since it's in, we can fix it
during the freeze if it turns out to be broken. Thanks,
Alex
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions Alexey Kardashevskiy
2018-02-12 5:19 ` David Gibson
@ 2018-03-19 20:49 ` Auger Eric
2018-03-21 15:29 ` Alex Williamson
1 sibling, 1 reply; 34+ messages in thread
From: Auger Eric @ 2018-03-19 20:49 UTC (permalink / raw)
To: Alexey Kardashevskiy, qemu-devel; +Cc: Alex Williamson, qemu-ppc, David Gibson
Hi Alexey,
On 09/02/18 08:55, Alexey Kardashevskiy wrote:
> At the moment if vfio_memory_listener is registered in the system memory
> address space, it maps/unmaps every RAM memory region for DMA.
> It expects system page size aligned memory sections so vfio_dma_map
> would not fail and so far this has been the case. A mapping failure
> would be fatal. A side effect of such behavior is that some MMIO pages
> would not be mapped silently.
>
> However we are going to change MSIX BAR handling so we will end having
> non-aligned sections in vfio_memory_listener (more details is in
> the next patch) and vfio_dma_map will exit QEMU.
>
> In order to avoid fatal failures on what previously was not a failure and
> was just silently ignored, this checks the section alignment to
> the smallest supported IOMMU page size and prints an error if not aligned;
> it also prints an error if vfio_dma_map failed despite the page size check.
> Both errors are not fatal; only MMIO RAM regions are checked
> (aka "RAM device" regions).
>
> If the amount of errors printed is overwhelming, the MSIX relocation
> could be used to avoid excessive error output.
>
> This is unlikely to cause any behavioral change.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> hw/vfio/common.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index f895e3c..736f271 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -544,18 +544,40 @@ static void vfio_listener_region_add(MemoryListener *listener,
>
> llsize = int128_sub(llend, int128_make64(iova));
>
> + if (memory_region_is_ram_device(section->mr)) {
> + hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
> +
> + if ((iova & pgmask) || (llsize & pgmask)) {
> + error_report("Region 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx
> + " is not aligned to 0x%"HWADDR_PRIx
> + " and cannot be mapped for DMA",
> + section->offset_within_region,
> + int128_getlo(section->size),
Didn't you want to print the section->offset_within_address_space
instead of section->offset_within_region?
For an 1000e card*, with a 64kB page, it outputs:
"Region 0x50..0xffb0 is not aligned to 0x10000 and cannot be mapped for DMA"
an absolute gpa range would be simpler I think.
* where Region 3: Memory at 100e0000 (32-bit, non-prefetchable)
[size=16K] contains the MSIX table
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00002000
Thanks
Eric
> + pgmask + 1);
> + return;
> + }
> + }
> +
> ret = vfio_dma_map(container, iova, int128_get64(llsize),
> vaddr, section->readonly);
> if (ret) {
> error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
> "0x%"HWADDR_PRIx", %p) = %d (%m)",
> container, iova, int128_get64(llsize), vaddr, ret);
> + if (memory_region_is_ram_device(section->mr)) {
> + /* Allow unexpected mappings not to be fatal for RAM devices */
> + return;
> + }
> goto fail;
> }
>
> return;
>
> fail:
> + if (memory_region_is_ram_device(section->mr)) {
> + error_report("failed to vfio_dma_map. pci p2p may not work");
> + return;
> + }
> /*
> * On the initfn path, store the first error in the container so we
> * can gracefully fail. Runtime, there's not much we can do other
> @@ -577,6 +599,7 @@ static void vfio_listener_region_del(MemoryListener *listener,
> hwaddr iova, end;
> Int128 llend, llsize;
> int ret;
> + bool try_unmap = true;
>
> if (vfio_listener_skipped_section(section)) {
> trace_vfio_listener_region_del_skip(
> @@ -629,13 +652,33 @@ static void vfio_listener_region_del(MemoryListener *listener,
>
> trace_vfio_listener_region_del(iova, end);
>
> - ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
> + if (memory_region_is_ram_device(section->mr)) {
> + hwaddr pgmask;
> + VFIOHostDMAWindow *hostwin;
> + bool hostwin_found = false;
> +
> + QLIST_FOREACH(hostwin, &container->hostwin_list, hostwin_next) {
> + if (hostwin->min_iova <= iova && end <= hostwin->max_iova) {
> + hostwin_found = true;
> + break;
> + }
> + }
> + assert(hostwin_found); /* or region_add() would have failed */
> +
> + pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
> + try_unmap = !((iova & pgmask) || (llsize & pgmask));
> + }
> +
> + if (try_unmap) {
> + ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
> + if (ret) {
> + error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
> + "0x%"HWADDR_PRIx") = %d (%m)",
> + container, iova, int128_get64(llsize), ret);
> + }
> + }
> +
> memory_region_unref(section->mr);
> - if (ret) {
> - error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
> - "0x%"HWADDR_PRIx") = %d (%m)",
> - container, iova, int128_get64(llsize), ret);
> - }
>
> if (container->iommu_type == VFIO_SPAPR_TCE_v2_IOMMU) {
> vfio_spapr_remove_window(container,
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-19 20:49 ` Auger Eric
@ 2018-03-21 15:29 ` Alex Williamson
2018-03-22 7:45 ` Alexey Kardashevskiy
0 siblings, 1 reply; 34+ messages in thread
From: Alex Williamson @ 2018-03-21 15:29 UTC (permalink / raw)
To: Auger Eric; +Cc: Alexey Kardashevskiy, qemu-devel, qemu-ppc, David Gibson
On Mon, 19 Mar 2018 21:49:58 +0100
Auger Eric <eric.auger@redhat.com> wrote:
> Hi Alexey,
>
> On 09/02/18 08:55, Alexey Kardashevskiy wrote:
> > At the moment if vfio_memory_listener is registered in the system memory
> > address space, it maps/unmaps every RAM memory region for DMA.
> > It expects system page size aligned memory sections so vfio_dma_map
> > would not fail and so far this has been the case. A mapping failure
> > would be fatal. A side effect of such behavior is that some MMIO pages
> > would not be mapped silently.
> >
> > However we are going to change MSIX BAR handling so we will end having
> > non-aligned sections in vfio_memory_listener (more details is in
> > the next patch) and vfio_dma_map will exit QEMU.
> >
> > In order to avoid fatal failures on what previously was not a failure and
> > was just silently ignored, this checks the section alignment to
> > the smallest supported IOMMU page size and prints an error if not aligned;
> > it also prints an error if vfio_dma_map failed despite the page size check.
> > Both errors are not fatal; only MMIO RAM regions are checked
> > (aka "RAM device" regions).
> >
> > If the amount of errors printed is overwhelming, the MSIX relocation
> > could be used to avoid excessive error output.
> >
> > This is unlikely to cause any behavioral change.
> >
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> > hw/vfio/common.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++------
> > 1 file changed, 49 insertions(+), 6 deletions(-)
> >
> > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > index f895e3c..736f271 100644
> > --- a/hw/vfio/common.c
> > +++ b/hw/vfio/common.c
> > @@ -544,18 +544,40 @@ static void vfio_listener_region_add(MemoryListener *listener,
> >
> > llsize = int128_sub(llend, int128_make64(iova));
> >
> > + if (memory_region_is_ram_device(section->mr)) {
> > + hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
> > +
> > + if ((iova & pgmask) || (llsize & pgmask)) {
> > + error_report("Region 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx
> > + " is not aligned to 0x%"HWADDR_PRIx
> > + " and cannot be mapped for DMA",
> > + section->offset_within_region,
> > + int128_getlo(section->size),
> Didn't you want to print the section->offset_within_address_space
> instead of section->offset_within_region?
>
> For an 1000e card*, with a 64kB page, it outputs:
> "Region 0x50..0xffb0 is not aligned to 0x10000 and cannot be mapped for DMA"
>
> an absolute gpa range would be simpler I think.
I agree, the offset within the address space seems like it'd be much
easier to map back to the device. Since we're handling it as
non-fatal, perhaps we can even add "MMIO Region" to give the user a bit
more context where the issue occurs. Alexey, do you want to submit a
follow-up patch, or Eric, you may have the best resources to tune the
message. Thanks,
Alex
> * where Region 3: Memory at 100e0000 (32-bit, non-prefetchable)
> [size=16K] contains the MSIX table
>
> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
> Vector table: BAR=3 offset=00000000
> PBA: BAR=3 offset=00002000
>
> Thanks
>
> Eric
> > + pgmask + 1);
> > + return;
> > + }
> > + }
> > +
> > ret = vfio_dma_map(container, iova, int128_get64(llsize),
> > vaddr, section->readonly);
> > if (ret) {
> > error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
> > "0x%"HWADDR_PRIx", %p) = %d (%m)",
> > container, iova, int128_get64(llsize), vaddr, ret);
> > + if (memory_region_is_ram_device(section->mr)) {
> > + /* Allow unexpected mappings not to be fatal for RAM devices */
> > + return;
> > + }
> > goto fail;
> > }
> >
> > return;
> >
> > fail:
> > + if (memory_region_is_ram_device(section->mr)) {
> > + error_report("failed to vfio_dma_map. pci p2p may not work");
> > + return;
> > + }
> > /*
> > * On the initfn path, store the first error in the container so we
> > * can gracefully fail. Runtime, there's not much we can do other
> > @@ -577,6 +599,7 @@ static void vfio_listener_region_del(MemoryListener *listener,
> > hwaddr iova, end;
> > Int128 llend, llsize;
> > int ret;
> > + bool try_unmap = true;
> >
> > if (vfio_listener_skipped_section(section)) {
> > trace_vfio_listener_region_del_skip(
> > @@ -629,13 +652,33 @@ static void vfio_listener_region_del(MemoryListener *listener,
> >
> > trace_vfio_listener_region_del(iova, end);
> >
> > - ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
> > + if (memory_region_is_ram_device(section->mr)) {
> > + hwaddr pgmask;
> > + VFIOHostDMAWindow *hostwin;
> > + bool hostwin_found = false;
> > +
> > + QLIST_FOREACH(hostwin, &container->hostwin_list, hostwin_next) {
> > + if (hostwin->min_iova <= iova && end <= hostwin->max_iova) {
> > + hostwin_found = true;
> > + break;
> > + }
> > + }
> > + assert(hostwin_found); /* or region_add() would have failed */
> > +
> > + pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
> > + try_unmap = !((iova & pgmask) || (llsize & pgmask));
> > + }
> > +
> > + if (try_unmap) {
> > + ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
> > + if (ret) {
> > + error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
> > + "0x%"HWADDR_PRIx") = %d (%m)",
> > + container, iova, int128_get64(llsize), ret);
> > + }
> > + }
> > +
> > memory_region_unref(section->mr);
> > - if (ret) {
> > - error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
> > - "0x%"HWADDR_PRIx") = %d (%m)",
> > - container, iova, int128_get64(llsize), ret);
> > - }
> >
> > if (container->iommu_type == VFIO_SPAPR_TCE_v2_IOMMU) {
> > vfio_spapr_remove_window(container,
> >
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-21 15:29 ` Alex Williamson
@ 2018-03-22 7:45 ` Alexey Kardashevskiy
2018-03-22 7:48 ` Auger Eric
0 siblings, 1 reply; 34+ messages in thread
From: Alexey Kardashevskiy @ 2018-03-22 7:45 UTC (permalink / raw)
To: Alex Williamson, Auger Eric; +Cc: qemu-devel, qemu-ppc, David Gibson
On 22/3/18 2:29 am, Alex Williamson wrote:
> On Mon, 19 Mar 2018 21:49:58 +0100
> Auger Eric <eric.auger@redhat.com> wrote:
>
>> Hi Alexey,
>>
>> On 09/02/18 08:55, Alexey Kardashevskiy wrote:
>>> At the moment if vfio_memory_listener is registered in the system memory
>>> address space, it maps/unmaps every RAM memory region for DMA.
>>> It expects system page size aligned memory sections so vfio_dma_map
>>> would not fail and so far this has been the case. A mapping failure
>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>> would not be mapped silently.
>>>
>>> However we are going to change MSIX BAR handling so we will end having
>>> non-aligned sections in vfio_memory_listener (more details is in
>>> the next patch) and vfio_dma_map will exit QEMU.
>>>
>>> In order to avoid fatal failures on what previously was not a failure and
>>> was just silently ignored, this checks the section alignment to
>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>> Both errors are not fatal; only MMIO RAM regions are checked
>>> (aka "RAM device" regions).
>>>
>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>> could be used to avoid excessive error output.
>>>
>>> This is unlikely to cause any behavioral change.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>> ---
>>> hw/vfio/common.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++------
>>> 1 file changed, 49 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>>> index f895e3c..736f271 100644
>>> --- a/hw/vfio/common.c
>>> +++ b/hw/vfio/common.c
>>> @@ -544,18 +544,40 @@ static void vfio_listener_region_add(MemoryListener *listener,
>>>
>>> llsize = int128_sub(llend, int128_make64(iova));
>>>
>>> + if (memory_region_is_ram_device(section->mr)) {
>>> + hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
>>> +
>>> + if ((iova & pgmask) || (llsize & pgmask)) {
>>> + error_report("Region 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx
>>> + " is not aligned to 0x%"HWADDR_PRIx
>>> + " and cannot be mapped for DMA",
>>> + section->offset_within_region,
>>> + int128_getlo(section->size),
>> Didn't you want to print the section->offset_within_address_space
>> instead of section->offset_within_region?
I do, my bad - this offset_within_region is a leftover from an earlier
version, iova is offset_within_address_space essentially.
>>
>> For an 1000e card*, with a 64kB page, it outputs:
>> "Region 0x50..0xffb0 is not aligned to 0x10000 and cannot be mapped for DMA"
>>
>> an absolute gpa range would be simpler I think.
>
> I agree, the offset within the address space seems like it'd be much
> easier to map back to the device. Since we're handling it as
> non-fatal, perhaps we can even add "MMIO Region" to give the user a bit
> more context where the issue occurs. Alexey, do you want to submit a
> follow-up patch, or Eric, you may have the best resources to tune the
> message. Thanks,
I can if somebody gives a hint about what needs to be tuned in the message.
I am also fine if Eric does this too :)
>
> Alex
>
>> * where Region 3: Memory at 100e0000 (32-bit, non-prefetchable)
>> [size=16K] contains the MSIX table
>>
>> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
>> Vector table: BAR=3 offset=00000000
>> PBA: BAR=3 offset=00002000
>>
>> Thanks
>>
>> Eric
>>> + pgmask + 1);
>>> + return;
>>> + }
>>> + }
>>> +
>>> ret = vfio_dma_map(container, iova, int128_get64(llsize),
>>> vaddr, section->readonly);
>>> if (ret) {
>>> error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
>>> "0x%"HWADDR_PRIx", %p) = %d (%m)",
>>> container, iova, int128_get64(llsize), vaddr, ret);
>>> + if (memory_region_is_ram_device(section->mr)) {
>>> + /* Allow unexpected mappings not to be fatal for RAM devices */
>>> + return;
>>> + }
>>> goto fail;
>>> }
>>>
>>> return;
>>>
>>> fail:
>>> + if (memory_region_is_ram_device(section->mr)) {
>>> + error_report("failed to vfio_dma_map. pci p2p may not work");
>>> + return;
>>> + }
>>> /*
>>> * On the initfn path, store the first error in the container so we
>>> * can gracefully fail. Runtime, there's not much we can do other
>>> @@ -577,6 +599,7 @@ static void vfio_listener_region_del(MemoryListener *listener,
>>> hwaddr iova, end;
>>> Int128 llend, llsize;
>>> int ret;
>>> + bool try_unmap = true;
>>>
>>> if (vfio_listener_skipped_section(section)) {
>>> trace_vfio_listener_region_del_skip(
>>> @@ -629,13 +652,33 @@ static void vfio_listener_region_del(MemoryListener *listener,
>>>
>>> trace_vfio_listener_region_del(iova, end);
>>>
>>> - ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
>>> + if (memory_region_is_ram_device(section->mr)) {
>>> + hwaddr pgmask;
>>> + VFIOHostDMAWindow *hostwin;
>>> + bool hostwin_found = false;
>>> +
>>> + QLIST_FOREACH(hostwin, &container->hostwin_list, hostwin_next) {
>>> + if (hostwin->min_iova <= iova && end <= hostwin->max_iova) {
>>> + hostwin_found = true;
>>> + break;
>>> + }
>>> + }
>>> + assert(hostwin_found); /* or region_add() would have failed */
>>> +
>>> + pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
>>> + try_unmap = !((iova & pgmask) || (llsize & pgmask));
>>> + }
>>> +
>>> + if (try_unmap) {
>>> + ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
>>> + if (ret) {
>>> + error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
>>> + "0x%"HWADDR_PRIx") = %d (%m)",
>>> + container, iova, int128_get64(llsize), ret);
>>> + }
>>> + }
>>> +
>>> memory_region_unref(section->mr);
>>> - if (ret) {
>>> - error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
>>> - "0x%"HWADDR_PRIx") = %d (%m)",
>>> - container, iova, int128_get64(llsize), ret);
>>> - }
>>>
>>> if (container->iommu_type == VFIO_SPAPR_TCE_v2_IOMMU) {
>>> vfio_spapr_remove_window(container,
>>>
>
--
Alexey
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions
2018-03-22 7:45 ` Alexey Kardashevskiy
@ 2018-03-22 7:48 ` Auger Eric
0 siblings, 0 replies; 34+ messages in thread
From: Auger Eric @ 2018-03-22 7:48 UTC (permalink / raw)
To: Alexey Kardashevskiy, Alex Williamson; +Cc: qemu-devel, qemu-ppc, David Gibson
Hi Alexey,
On 22/03/18 08:45, Alexey Kardashevskiy wrote:
> On 22/3/18 2:29 am, Alex Williamson wrote:
>> On Mon, 19 Mar 2018 21:49:58 +0100
>> Auger Eric <eric.auger@redhat.com> wrote:
>>
>>> Hi Alexey,
>>>
>>> On 09/02/18 08:55, Alexey Kardashevskiy wrote:
>>>> At the moment if vfio_memory_listener is registered in the system memory
>>>> address space, it maps/unmaps every RAM memory region for DMA.
>>>> It expects system page size aligned memory sections so vfio_dma_map
>>>> would not fail and so far this has been the case. A mapping failure
>>>> would be fatal. A side effect of such behavior is that some MMIO pages
>>>> would not be mapped silently.
>>>>
>>>> However we are going to change MSIX BAR handling so we will end having
>>>> non-aligned sections in vfio_memory_listener (more details is in
>>>> the next patch) and vfio_dma_map will exit QEMU.
>>>>
>>>> In order to avoid fatal failures on what previously was not a failure and
>>>> was just silently ignored, this checks the section alignment to
>>>> the smallest supported IOMMU page size and prints an error if not aligned;
>>>> it also prints an error if vfio_dma_map failed despite the page size check.
>>>> Both errors are not fatal; only MMIO RAM regions are checked
>>>> (aka "RAM device" regions).
>>>>
>>>> If the amount of errors printed is overwhelming, the MSIX relocation
>>>> could be used to avoid excessive error output.
>>>>
>>>> This is unlikely to cause any behavioral change.
>>>>
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>> ---
>>>> hw/vfio/common.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++------
>>>> 1 file changed, 49 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>>>> index f895e3c..736f271 100644
>>>> --- a/hw/vfio/common.c
>>>> +++ b/hw/vfio/common.c
>>>> @@ -544,18 +544,40 @@ static void vfio_listener_region_add(MemoryListener *listener,
>>>>
>>>> llsize = int128_sub(llend, int128_make64(iova));
>>>>
>>>> + if (memory_region_is_ram_device(section->mr)) {
>>>> + hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
>>>> +
>>>> + if ((iova & pgmask) || (llsize & pgmask)) {
>>>> + error_report("Region 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx
>>>> + " is not aligned to 0x%"HWADDR_PRIx
>>>> + " and cannot be mapped for DMA",
>>>> + section->offset_within_region,
>>>> + int128_getlo(section->size),
>>> Didn't you want to print the section->offset_within_address_space
>>> instead of section->offset_within_region?
>
>
> I do, my bad - this offset_within_region is a leftover from an earlier
> version, iova is offset_within_address_space essentially.
>
>
>>>
>>> For an 1000e card*, with a 64kB page, it outputs:
>>> "Region 0x50..0xffb0 is not aligned to 0x10000 and cannot be mapped for DMA"
>>>
>>> an absolute gpa range would be simpler I think.
>>
>> I agree, the offset within the address space seems like it'd be much
>> easier to map back to the device. Since we're handling it as
>> non-fatal, perhaps we can even add "MMIO Region" to give the user a bit
>> more context where the issue occurs. Alexey, do you want to submit a
>> follow-up patch, or Eric, you may have the best resources to tune the
>> message. Thanks,
>
>
> I can if somebody gives a hint about what needs to be tuned in the message.
> I am also fine if Eric does this too :)
I propose to send a follow-up patch as I have the proper HW to test it now.
Thanks
Eric
>
>
>>
>> Alex
>>
>>> * where Region 3: Memory at 100e0000 (32-bit, non-prefetchable)
>>> [size=16K] contains the MSIX table
>>>
>>> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
>>> Vector table: BAR=3 offset=00000000
>>> PBA: BAR=3 offset=00002000
>>>
>>> Thanks
>>>
>>> Eric
>>>> + pgmask + 1);
>>>> + return;
>>>> + }
>>>> + }
>>>> +
>>>> ret = vfio_dma_map(container, iova, int128_get64(llsize),
>>>> vaddr, section->readonly);
>>>> if (ret) {
>>>> error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
>>>> "0x%"HWADDR_PRIx", %p) = %d (%m)",
>>>> container, iova, int128_get64(llsize), vaddr, ret);
>>>> + if (memory_region_is_ram_device(section->mr)) {
>>>> + /* Allow unexpected mappings not to be fatal for RAM devices */
>>>> + return;
>>>> + }
>>>> goto fail;
>>>> }
>>>>
>>>> return;
>>>>
>>>> fail:
>>>> + if (memory_region_is_ram_device(section->mr)) {
>>>> + error_report("failed to vfio_dma_map. pci p2p may not work");
>>>> + return;
>>>> + }
>>>> /*
>>>> * On the initfn path, store the first error in the container so we
>>>> * can gracefully fail. Runtime, there's not much we can do other
>>>> @@ -577,6 +599,7 @@ static void vfio_listener_region_del(MemoryListener *listener,
>>>> hwaddr iova, end;
>>>> Int128 llend, llsize;
>>>> int ret;
>>>> + bool try_unmap = true;
>>>>
>>>> if (vfio_listener_skipped_section(section)) {
>>>> trace_vfio_listener_region_del_skip(
>>>> @@ -629,13 +652,33 @@ static void vfio_listener_region_del(MemoryListener *listener,
>>>>
>>>> trace_vfio_listener_region_del(iova, end);
>>>>
>>>> - ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
>>>> + if (memory_region_is_ram_device(section->mr)) {
>>>> + hwaddr pgmask;
>>>> + VFIOHostDMAWindow *hostwin;
>>>> + bool hostwin_found = false;
>>>> +
>>>> + QLIST_FOREACH(hostwin, &container->hostwin_list, hostwin_next) {
>>>> + if (hostwin->min_iova <= iova && end <= hostwin->max_iova) {
>>>> + hostwin_found = true;
>>>> + break;
>>>> + }
>>>> + }
>>>> + assert(hostwin_found); /* or region_add() would have failed */
>>>> +
>>>> + pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
>>>> + try_unmap = !((iova & pgmask) || (llsize & pgmask));
>>>> + }
>>>> +
>>>> + if (try_unmap) {
>>>> + ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
>>>> + if (ret) {
>>>> + error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
>>>> + "0x%"HWADDR_PRIx") = %d (%m)",
>>>> + container, iova, int128_get64(llsize), ret);
>>>> + }
>>>> + }
>>>> +
>>>> memory_region_unref(section->mr);
>>>> - if (ret) {
>>>> - error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
>>>> - "0x%"HWADDR_PRIx") = %d (%m)",
>>>> - container, iova, int128_get64(llsize), ret);
>>>> - }
>>>>
>>>> if (container->iommu_type == VFIO_SPAPR_TCE_v2_IOMMU) {
>>>> vfio_spapr_remove_window(container,
>>>>
>>
>
>
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2018-03-22 7:49 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-09 7:54 [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 1/4] linux-headers: update to f1517df8701c Alexey Kardashevskiy
2018-02-10 7:34 ` David Gibson
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions Alexey Kardashevskiy
2018-02-12 5:19 ` David Gibson
2018-02-12 7:05 ` Alexey Kardashevskiy
2018-02-12 16:06 ` Alex Williamson
2018-02-13 1:15 ` Alexey Kardashevskiy
2018-02-13 5:36 ` David Gibson
2018-02-13 5:41 ` David Gibson
2018-02-13 8:20 ` Alexey Kardashevskiy
2018-02-14 1:33 ` David Gibson
2018-02-14 8:09 ` Alexey Kardashevskiy
2018-02-14 15:55 ` Alex Williamson
2018-02-16 5:28 ` David Gibson
2018-02-19 2:46 ` Alexey Kardashevskiy
2018-02-26 8:36 ` Alexey Kardashevskiy
2018-03-07 2:17 ` Alexey Kardashevskiy
2018-03-13 4:53 ` Alexey Kardashevskiy
2018-03-13 16:56 ` Alex Williamson
2018-03-13 17:13 ` Auger Eric
2018-03-13 19:17 ` Eric Blake
2018-03-14 2:40 ` Alexey Kardashevskiy
2018-03-15 2:36 ` Alex Williamson
2018-03-19 20:49 ` Auger Eric
2018-03-21 15:29 ` Alex Williamson
2018-03-22 7:45 ` Alexey Kardashevskiy
2018-03-22 7:48 ` Auger Eric
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 3/4] vfio-pci: Allow mmap of MSIX BAR Alexey Kardashevskiy
2018-02-13 5:39 ` David Gibson
2018-02-09 7:55 ` [Qemu-devel] [PATCH qemu v7 4/4] ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices Alexey Kardashevskiy
2018-02-13 5:43 ` David Gibson
2018-02-09 8:04 ` [Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR no-reply
2018-02-09 8:05 ` no-reply
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.