2010-08-31 23:41:25 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2011 Citrix Ltd.
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2. See
|
|
|
|
* the COPYING file in the top-level directory.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef XEN_MAPCACHE_H
|
|
|
|
#define XEN_MAPCACHE_H
|
|
|
|
|
2012-10-23 18:30:10 +08:00
|
|
|
typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr start_addr,
|
2012-01-18 20:21:38 +08:00
|
|
|
ram_addr_t size,
|
|
|
|
void *opaque);
|
2011-07-20 17:14:06 +08:00
|
|
|
#ifdef CONFIG_XEN
|
|
|
|
|
2012-01-18 20:21:38 +08:00
|
|
|
void xen_map_cache_init(phys_offset_to_gaddr_t f,
|
|
|
|
void *opaque);
|
2012-10-23 18:30:10 +08:00
|
|
|
uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
|
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>
2017-05-04 05:00:35 +08:00
|
|
|
uint8_t lock, bool dma);
|
2011-06-22 04:59:08 +08:00
|
|
|
ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
|
|
|
|
void xen_invalidate_map_cache_entry(uint8_t *buffer);
|
|
|
|
void xen_invalidate_map_cache(void);
|
2017-07-11 06:40:02 +08:00
|
|
|
uint8_t *xen_replace_cache_entry(hwaddr old_phys_addr,
|
|
|
|
hwaddr new_phys_addr,
|
|
|
|
hwaddr size);
|
2011-07-20 17:14:06 +08:00
|
|
|
#else
|
|
|
|
|
2012-01-18 20:21:38 +08:00
|
|
|
static inline void xen_map_cache_init(phys_offset_to_gaddr_t f,
|
|
|
|
void *opaque)
|
2011-07-20 17:14:06 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2012-10-23 18:30:10 +08:00
|
|
|
static inline uint8_t *xen_map_cache(hwaddr phys_addr,
|
|
|
|
hwaddr size,
|
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>
2017-05-04 05:00:35 +08:00
|
|
|
uint8_t lock,
|
|
|
|
bool dma)
|
2011-07-20 17:14:06 +08:00
|
|
|
{
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
|
|
|
|
{
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void xen_invalidate_map_cache_entry(uint8_t *buffer)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void xen_invalidate_map_cache(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2017-07-11 06:40:02 +08:00
|
|
|
static inline uint8_t *xen_replace_cache_entry(hwaddr old_phys_addr,
|
|
|
|
hwaddr new_phys_addr,
|
|
|
|
hwaddr size)
|
|
|
|
{
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
2011-07-20 17:14:06 +08:00
|
|
|
#endif
|
|
|
|
|
2016-06-29 21:29:06 +08:00
|
|
|
#endif /* XEN_MAPCACHE_H */
|