diff options
| author | Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> | 2017-05-03 14:52:34 -0600 |
|---|---|---|
| committer | Alex Williamson <alex.williamson@redhat.com> | 2017-05-03 14:52:34 -0600 |
| commit | 15126cba8618ac6cf4dde320ff9cd96ad0640d5d (patch) | |
| tree | da522e11548f407468e6cd06bb86ae1ef4ae90ff /hw | |
| parent | e619b14746e5d8c0e53061661fd0e1da01fd4d60 (diff) | |
| download | qemu-15126cba8618ac6cf4dde320ff9cd96ad0640d5d.zip qemu-15126cba8618ac6cf4dde320ff9cd96ad0640d5d.tar.gz qemu-15126cba8618ac6cf4dde320ff9cd96ad0640d5d.tar.bz2 | |
vfio: Set MemoryRegionOps:max_access_size and min_access_size
Sets valid.max_access_size and valid.min_access_size to ensure safe
8-byte accesses to vfio. Today, 8-byte accesses are broken into pairs
of 4-byte calls that goes unprotected:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
which occasionally leads to:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2030c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x1000c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
causing strange errors in guest OS. With this patch, such accesses
are protected by the same lock guard:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4)
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
This happens because the 8-byte write should be broken into 4-byte
writes by memory.c:access_with_adjusted_size() in order to be under
the same lock. Today, it's done in exec.c:address_space_write_continue()
which was able to handle only 4 bytes due to a zero'ed
valid.max_access_size (see exec.c:memory_access_size()).
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Diffstat (limited to 'hw')
| -rw-r--r-- | hw/vfio/common.c | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/hw/vfio/common.c b/hw/vfio/common.c index 6b33b9f..6572c07 100644 --- a/hw/vfio/common.c +++ b/hw/vfio/common.c @@ -190,6 +190,10 @@ const MemoryRegionOps vfio_region_ops = { .read = vfio_region_read, .write = vfio_region_write, .endianness = DEVICE_LITTLE_ENDIAN, + .valid = { + .min_access_size = 1, + .max_access_size = 8, + }, }; /* |