mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-03 07:43:54 -06:00
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>
This commit is contained in:
parent
cdece0467c
commit
1ff7c5986a
3 changed files with 17 additions and 11 deletions
8
exec.c
8
exec.c
|
@ -2084,10 +2084,10 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t addr)
|
|||
* In that case just map until the end of the page.
|
||||
*/
|
||||
if (block->offset == 0) {
|
||||
return xen_map_cache(addr, 0, 0);
|
||||
return xen_map_cache(addr, 0, 0, false);
|
||||
}
|
||||
|
||||
block->host = xen_map_cache(block->offset, block->max_length, 1);
|
||||
block->host = xen_map_cache(block->offset, block->max_length, 1, false);
|
||||
}
|
||||
return ramblock_ptr(block, addr);
|
||||
}
|
||||
|
@ -2117,10 +2117,10 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, ram_addr_t addr,
|
|||
* In that case just map the requested area.
|
||||
*/
|
||||
if (block->offset == 0) {
|
||||
return xen_map_cache(addr, *size, 1);
|
||||
return xen_map_cache(addr, *size, 1, true);
|
||||
}
|
||||
|
||||
block->host = xen_map_cache(block->offset, block->max_length, 1);
|
||||
block->host = xen_map_cache(block->offset, block->max_length, 1, true);
|
||||
}
|
||||
|
||||
return ramblock_ptr(block, addr);
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue