aboutsummaryrefslogtreecommitdiff
path: root/hw/i386/xen
diff options
context:
space:
mode:
authorStefano Stabellini <sstabellini@kernel.org>2017-05-03 14:00:35 -0700
committerStefano Stabellini <sstabellini@kernel.org>2017-05-16 11:49:09 -0700
commit1ff7c5986a515d2d936eba026ff19947bbc7cb92 (patch)
tree66bc3e4afe6223b30a7dfd169203a5ad01758e77 /hw/i386/xen
parentcdece0467c00007cf8e3f4b3c3f0b13bf2c4fea9 (diff)
downloadqemu-1ff7c5986a515d2d936eba026ff19947bbc7cb92.zip
qemu-1ff7c5986a515d2d936eba026ff19947bbc7cb92.tar.gz
qemu-1ff7c5986a515d2d936eba026ff19947bbc7cb92.tar.bz2
xen/mapcache: store dma information in revmapcache entries for debugging
The Xen mapcache is able to create long term mappings, they are called "locked" mappings. The third parameter of the xen_map_cache call specifies if a mapping is a "locked" mapping. >From the QEMU point of view there are two kinds of long term mappings: [a] device memory mappings, such as option roms and video memory [b] dma mappings, created by dma_memory_map & friends After certain operations, ballooning a VM in particular, Xen asks QEMU kindly to destroy all mappings. However, certainly [a] mappings are present and cannot be removed. That's not a problem as they are not affected by balloonning. The *real* problem is that if there are any mappings of type [b], any outstanding dma operations could fail. This is a known shortcoming. In other words, when Xen asks QEMU to destroy all mappings, it is an error if any [b] mappings exist. However today we have no way of distinguishing [a] from [b]. Because of that, we cannot even print a decent warning. This patch introduces a new "dma" bool field to MapCacheRev entires, to remember if a given mapping is for dma or is a long term device memory mapping. When xen_invalidate_map_cache is called, we print a warning if any [b] mappings exist. We ignore [a] mappings. Mappings created by qemu_map_ram_ptr are assumed to be [a], while mappings created by address_space_map->qemu_ram_ptr_length are assumed to be [b]. The goal of the patch is to make debugging and system understanding easier. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Diffstat (limited to 'hw/i386/xen')
-rw-r--r--hw/i386/xen/xen-mapcache.c15
1 files changed, 10 insertions, 5 deletions
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 31debdf..e60156c 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -62,6 +62,7 @@ typedef struct MapCacheRev {
hwaddr paddr_index;
hwaddr size;
QTAILQ_ENTRY(MapCacheRev) next;
+ bool dma;
} MapCacheRev;
typedef struct MapCache {
@@ -202,7 +203,7 @@ static void xen_remap_bucket(MapCacheEntry *entry,
}
static uint8_t *xen_map_cache_unlocked(hwaddr phys_addr, hwaddr size,
- uint8_t lock)
+ uint8_t lock, bool dma)
{
MapCacheEntry *entry, *pentry = NULL;
hwaddr address_index;
@@ -289,6 +290,7 @@ tryagain:
if (lock) {
MapCacheRev *reventry = g_malloc0(sizeof(MapCacheRev));
entry->lock++;
+ reventry->dma = dma;
reventry->vaddr_req = mapcache->last_entry->vaddr_base + address_offset;
reventry->paddr_index = mapcache->last_entry->paddr_index;
reventry->size = entry->size;
@@ -300,12 +302,12 @@ tryagain:
}
uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
- uint8_t lock)
+ uint8_t lock, bool dma)
{
uint8_t *p;
mapcache_lock();
- p = xen_map_cache_unlocked(phys_addr, size, lock);
+ p = xen_map_cache_unlocked(phys_addr, size, lock, dma);
mapcache_unlock();
return p;
}
@@ -426,8 +428,11 @@ void xen_invalidate_map_cache(void)
mapcache_lock();
QTAILQ_FOREACH(reventry, &mapcache->locked_entries, next) {
- DPRINTF("There should be no locked mappings at this time, "
- "but "TARGET_FMT_plx" -> %p is present\n",
+ if (!reventry->dma) {
+ continue;
+ }
+ fprintf(stderr, "Locked DMA mapping while invalidating mapcache!"
+ " "TARGET_FMT_plx" -> %p is present\n",
reventry->paddr_index, reventry->vaddr_req);
}