* [Qemu-devel] [PULL 0/4] please pull xen-20170516-tag
@ 2017-05-16 19:19 ` Stefano Stabellini
0 siblings, 0 replies; 12+ messages in thread
From: Stefano Stabellini @ 2017-05-16 19:19 UTC (permalink / raw)
To: peter.maydell, stefanha
Cc: sstabellini, stefanha, anthony.perard, xen-devel, qemu-devel
The following changes since commit cdece0467c00007cf8e3f4b3c3f0b13bf2c4fea9:
block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100)
are available in the git repository at:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170516-tag
for you to fetch changes up to 01cd90b641e1aed40cf13a577e6a737af94d55e7:
xen: call qemu_set_cloexec instead of fcntl (2017-05-16 11:51:25 -0700)
----------------------------------------------------------------
Xen 2017/05/16
----------------------------------------------------------------
Anthony PERARD (1):
configure: Remove -lxencall for Xen detection
Stefano Stabellini (3):
xen/mapcache: store dma information in revmapcache entries for debugging
xen/9pfs: fix two resource leaks on error paths, discovered by Coverity
xen: call qemu_set_cloexec instead of fcntl
configure | 2 +-
exec.c | 8 ++++----
hw/9pfs/xen-9p-backend.c | 4 +++-
hw/i386/xen/xen-mapcache.c | 15 ++++++++++-----
hw/xen/xen_backend.c | 2 +-
include/sysemu/xen-mapcache.h | 5 +++--
6 files changed, 22 insertions(+), 14 deletions(-)
^ permalink raw reply [flat|nested] 12+ messages in thread* [PULL 0/4] please pull xen-20170516-tag @ 2017-05-16 19:19 ` Stefano Stabellini 0 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:19 UTC (permalink / raw) To: peter.maydell, stefanha Cc: anthony.perard, xen-devel, sstabellini, qemu-devel, stefanha The following changes since commit cdece0467c00007cf8e3f4b3c3f0b13bf2c4fea9: block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170516-tag for you to fetch changes up to 01cd90b641e1aed40cf13a577e6a737af94d55e7: xen: call qemu_set_cloexec instead of fcntl (2017-05-16 11:51:25 -0700) ---------------------------------------------------------------- Xen 2017/05/16 ---------------------------------------------------------------- Anthony PERARD (1): configure: Remove -lxencall for Xen detection Stefano Stabellini (3): xen/mapcache: store dma information in revmapcache entries for debugging xen/9pfs: fix two resource leaks on error paths, discovered by Coverity xen: call qemu_set_cloexec instead of fcntl configure | 2 +- exec.c | 8 ++++---- hw/9pfs/xen-9p-backend.c | 4 +++- hw/i386/xen/xen-mapcache.c | 15 ++++++++++----- hw/xen/xen_backend.c | 2 +- include/sysemu/xen-mapcache.h | 5 +++-- 6 files changed, 22 insertions(+), 14 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Qemu-devel] [PULL 1/4] xen/mapcache: store dma information in revmapcache entries for debugging 2017-05-16 19:19 ` Stefano Stabellini @ 2017-05-16 19:21 ` Stefano Stabellini -1 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:21 UTC (permalink / raw) To: peter.maydell, stefanha Cc: sstabellini, stefanha, anthony.perard, xen-devel, qemu-devel 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> --- exec.c | 8 ++++---- hw/i386/xen/xen-mapcache.c | 15 ++++++++++----- include/sysemu/xen-mapcache.h | 5 +++-- 3 files changed, 17 insertions(+), 11 deletions(-) diff --git a/exec.c b/exec.c index eac6085..85769e1 100644 --- a/exec.c +++ b/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); 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); } diff --git a/include/sysemu/xen-mapcache.h b/include/sysemu/xen-mapcache.h index b8c93b9..01daaad 100644 --- a/include/sysemu/xen-mapcache.h +++ b/include/sysemu/xen-mapcache.h @@ -17,7 +17,7 @@ typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr start_addr, void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque); uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size, - uint8_t lock); + uint8_t lock, bool dma); 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); @@ -31,7 +31,8 @@ static inline void xen_map_cache_init(phys_offset_to_gaddr_t f, static inline uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size, - uint8_t lock) + uint8_t lock, + bool dma) { abort(); } -- 1.9.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PULL 1/4] xen/mapcache: store dma information in revmapcache entries for debugging @ 2017-05-16 19:21 ` Stefano Stabellini 0 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:21 UTC (permalink / raw) To: peter.maydell, stefanha Cc: anthony.perard, xen-devel, sstabellini, qemu-devel, stefanha 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> --- exec.c | 8 ++++---- hw/i386/xen/xen-mapcache.c | 15 ++++++++++----- include/sysemu/xen-mapcache.h | 5 +++-- 3 files changed, 17 insertions(+), 11 deletions(-) diff --git a/exec.c b/exec.c index eac6085..85769e1 100644 --- a/exec.c +++ b/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); 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); } diff --git a/include/sysemu/xen-mapcache.h b/include/sysemu/xen-mapcache.h index b8c93b9..01daaad 100644 --- a/include/sysemu/xen-mapcache.h +++ b/include/sysemu/xen-mapcache.h @@ -17,7 +17,7 @@ typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr start_addr, void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque); uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size, - uint8_t lock); + uint8_t lock, bool dma); 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); @@ -31,7 +31,8 @@ static inline void xen_map_cache_init(phys_offset_to_gaddr_t f, static inline uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size, - uint8_t lock) + uint8_t lock, + bool dma) { abort(); } -- 1.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [Qemu-devel] [PULL 2/4] configure: Remove -lxencall for Xen detection 2017-05-16 19:21 ` Stefano Stabellini @ 2017-05-16 19:21 ` Stefano Stabellini -1 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:21 UTC (permalink / raw) To: peter.maydell, stefanha Cc: sstabellini, stefanha, anthony.perard, xen-devel, qemu-devel From: Anthony PERARD <anthony.perard@citrix.com> QEMU does not depends on libxencall, it was added because it was a missing link dependency of libxendevicemodel, but now the later should be built properly. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 57b5ae6..139638e 100755 --- a/configure +++ b/configure @@ -2015,7 +2015,7 @@ if test "$xen" != "no" ; then else xen_libs="-lxenstore -lxenctrl -lxenguest" - xen_stable_libs="-lxencall -lxenforeignmemory -lxengnttab -lxenevtchn" + xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn" # First we test whether Xen headers and libraries are available. # If no, we are done and there is no Xen support. -- 1.9.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PULL 2/4] configure: Remove -lxencall for Xen detection @ 2017-05-16 19:21 ` Stefano Stabellini 0 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:21 UTC (permalink / raw) To: peter.maydell, stefanha Cc: anthony.perard, xen-devel, sstabellini, qemu-devel, stefanha From: Anthony PERARD <anthony.perard@citrix.com> QEMU does not depends on libxencall, it was added because it was a missing link dependency of libxendevicemodel, but now the later should be built properly. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 57b5ae6..139638e 100755 --- a/configure +++ b/configure @@ -2015,7 +2015,7 @@ if test "$xen" != "no" ; then else xen_libs="-lxenstore -lxenctrl -lxenguest" - xen_stable_libs="-lxencall -lxenforeignmemory -lxengnttab -lxenevtchn" + xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn" # First we test whether Xen headers and libraries are available. # If no, we are done and there is no Xen support. -- 1.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [Qemu-devel] [PULL 3/4] xen/9pfs: fix two resource leaks on error paths, discovered by Coverity 2017-05-16 19:21 ` Stefano Stabellini @ 2017-05-16 19:21 ` Stefano Stabellini -1 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:21 UTC (permalink / raw) To: peter.maydell, stefanha Cc: sstabellini, stefanha, anthony.perard, xen-devel, qemu-devel, groug, aneesh.kumar CID: 1374836 Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com --- hw/9pfs/xen-9p-backend.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c index 9c7f41a..a1fdede 100644 --- a/hw/9pfs/xen-9p-backend.c +++ b/hw/9pfs/xen-9p-backend.c @@ -332,12 +332,14 @@ static int xen_9pfs_connect(struct XenDevice *xendev) str = g_strdup_printf("ring-ref%u", i); if (xenstore_read_fe_int(&xen_9pdev->xendev, str, &xen_9pdev->rings[i].ref) == -1) { + g_free(str); goto out; } g_free(str); str = g_strdup_printf("event-channel-%u", i); if (xenstore_read_fe_int(&xen_9pdev->xendev, str, &xen_9pdev->rings[i].evtchn) == -1) { + g_free(str); goto out; } g_free(str); -- 1.9.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PULL 3/4] xen/9pfs: fix two resource leaks on error paths, discovered by Coverity @ 2017-05-16 19:21 ` Stefano Stabellini 0 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:21 UTC (permalink / raw) To: peter.maydell, stefanha Cc: sstabellini, qemu-devel, groug, aneesh.kumar, stefanha, anthony.perard, xen-devel CID: 1374836 Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com --- hw/9pfs/xen-9p-backend.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c index 9c7f41a..a1fdede 100644 --- a/hw/9pfs/xen-9p-backend.c +++ b/hw/9pfs/xen-9p-backend.c @@ -332,12 +332,14 @@ static int xen_9pfs_connect(struct XenDevice *xendev) str = g_strdup_printf("ring-ref%u", i); if (xenstore_read_fe_int(&xen_9pdev->xendev, str, &xen_9pdev->rings[i].ref) == -1) { + g_free(str); goto out; } g_free(str); str = g_strdup_printf("event-channel-%u", i); if (xenstore_read_fe_int(&xen_9pdev->xendev, str, &xen_9pdev->rings[i].evtchn) == -1) { + g_free(str); goto out; } g_free(str); -- 1.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [Qemu-devel] [PULL 4/4] xen: call qemu_set_cloexec instead of fcntl 2017-05-16 19:21 ` Stefano Stabellini @ 2017-05-16 19:21 ` Stefano Stabellini -1 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:21 UTC (permalink / raw) To: peter.maydell, stefanha Cc: sstabellini, stefanha, anthony.perard, xen-devel, qemu-devel, groug, aneesh.kumar, Eric Blake Use the common utility function, which contains checks on return values and first calls F_GETFD as recommended by POSIX.1-2001, instead of manually calling fcntl. CID: 1374831 Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com CC: Eric Blake <eblake@redhat.com> --- hw/9pfs/xen-9p-backend.c | 2 +- hw/xen/xen_backend.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c index a1fdede..5df97c9 100644 --- a/hw/9pfs/xen-9p-backend.c +++ b/hw/9pfs/xen-9p-backend.c @@ -380,7 +380,7 @@ static int xen_9pfs_connect(struct XenDevice *xendev) if (xen_9pdev->rings[i].evtchndev == NULL) { goto out; } - fcntl(xenevtchn_fd(xen_9pdev->rings[i].evtchndev), F_SETFD, FD_CLOEXEC); + qemu_set_cloexec(xenevtchn_fd(xen_9pdev->rings[i].evtchndev)); xen_9pdev->rings[i].local_port = xenevtchn_bind_interdomain (xen_9pdev->rings[i].evtchndev, xendev->dom, diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index c85f163..2cac47d 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -147,7 +147,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, qdev_unplug(DEVICE(xendev), NULL); return NULL; } - fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC); + qemu_set_cloexec(xenevtchn_fd(xendev->evtchndev)); if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) { xendev->gnttabdev = xengnttab_open(NULL, 0); -- 1.9.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PULL 4/4] xen: call qemu_set_cloexec instead of fcntl @ 2017-05-16 19:21 ` Stefano Stabellini 0 siblings, 0 replies; 12+ messages in thread From: Stefano Stabellini @ 2017-05-16 19:21 UTC (permalink / raw) To: peter.maydell, stefanha Cc: sstabellini, qemu-devel, groug, aneesh.kumar, stefanha, anthony.perard, xen-devel, Eric Blake Use the common utility function, which contains checks on return values and first calls F_GETFD as recommended by POSIX.1-2001, instead of manually calling fcntl. CID: 1374831 Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com CC: Eric Blake <eblake@redhat.com> --- hw/9pfs/xen-9p-backend.c | 2 +- hw/xen/xen_backend.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c index a1fdede..5df97c9 100644 --- a/hw/9pfs/xen-9p-backend.c +++ b/hw/9pfs/xen-9p-backend.c @@ -380,7 +380,7 @@ static int xen_9pfs_connect(struct XenDevice *xendev) if (xen_9pdev->rings[i].evtchndev == NULL) { goto out; } - fcntl(xenevtchn_fd(xen_9pdev->rings[i].evtchndev), F_SETFD, FD_CLOEXEC); + qemu_set_cloexec(xenevtchn_fd(xen_9pdev->rings[i].evtchndev)); xen_9pdev->rings[i].local_port = xenevtchn_bind_interdomain (xen_9pdev->rings[i].evtchndev, xendev->dom, diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index c85f163..2cac47d 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -147,7 +147,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, qdev_unplug(DEVICE(xendev), NULL); return NULL; } - fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC); + qemu_set_cloexec(xenevtchn_fd(xendev->evtchndev)); if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) { xendev->gnttabdev = xengnttab_open(NULL, 0); -- 1.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PULL 0/4] please pull xen-20170516-tag 2017-05-16 19:19 ` Stefano Stabellini @ 2017-05-17 13:04 ` Stefan Hajnoczi -1 siblings, 0 replies; 12+ messages in thread From: Stefan Hajnoczi @ 2017-05-17 13:04 UTC (permalink / raw) To: Stefano Stabellini Cc: peter.maydell, stefanha, anthony.perard, xen-devel, qemu-devel [-- Attachment #1: Type: text/plain, Size: 1446 bytes --] On Tue, May 16, 2017 at 12:19:26PM -0700, Stefano Stabellini wrote: > The following changes since commit cdece0467c00007cf8e3f4b3c3f0b13bf2c4fea9: > > block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100) > > are available in the git repository at: > > git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170516-tag > > for you to fetch changes up to 01cd90b641e1aed40cf13a577e6a737af94d55e7: > > xen: call qemu_set_cloexec instead of fcntl (2017-05-16 11:51:25 -0700) > > ---------------------------------------------------------------- > Xen 2017/05/16 > > ---------------------------------------------------------------- > Anthony PERARD (1): > configure: Remove -lxencall for Xen detection > > Stefano Stabellini (3): > xen/mapcache: store dma information in revmapcache entries for debugging > xen/9pfs: fix two resource leaks on error paths, discovered by Coverity > xen: call qemu_set_cloexec instead of fcntl > > configure | 2 +- > exec.c | 8 ++++---- > hw/9pfs/xen-9p-backend.c | 4 +++- > hw/i386/xen/xen-mapcache.c | 15 ++++++++++----- > hw/xen/xen_backend.c | 2 +- > include/sysemu/xen-mapcache.h | 5 +++-- > 6 files changed, 22 insertions(+), 14 deletions(-) Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PULL 0/4] please pull xen-20170516-tag @ 2017-05-17 13:04 ` Stefan Hajnoczi 0 siblings, 0 replies; 12+ messages in thread From: Stefan Hajnoczi @ 2017-05-17 13:04 UTC (permalink / raw) To: Stefano Stabellini Cc: anthony.perard, peter.maydell, qemu-devel, stefanha, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1446 bytes --] On Tue, May 16, 2017 at 12:19:26PM -0700, Stefano Stabellini wrote: > The following changes since commit cdece0467c00007cf8e3f4b3c3f0b13bf2c4fea9: > > block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100) > > are available in the git repository at: > > git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170516-tag > > for you to fetch changes up to 01cd90b641e1aed40cf13a577e6a737af94d55e7: > > xen: call qemu_set_cloexec instead of fcntl (2017-05-16 11:51:25 -0700) > > ---------------------------------------------------------------- > Xen 2017/05/16 > > ---------------------------------------------------------------- > Anthony PERARD (1): > configure: Remove -lxencall for Xen detection > > Stefano Stabellini (3): > xen/mapcache: store dma information in revmapcache entries for debugging > xen/9pfs: fix two resource leaks on error paths, discovered by Coverity > xen: call qemu_set_cloexec instead of fcntl > > configure | 2 +- > exec.c | 8 ++++---- > hw/9pfs/xen-9p-backend.c | 4 +++- > hw/i386/xen/xen-mapcache.c | 15 ++++++++++----- > hw/xen/xen_backend.c | 2 +- > include/sysemu/xen-mapcache.h | 5 +++-- > 6 files changed, 22 insertions(+), 14 deletions(-) Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 455 bytes --] [-- Attachment #2: Type: text/plain, Size: 127 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-05-17 13:04 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-16 19:19 [Qemu-devel] [PULL 0/4] please pull xen-20170516-tag Stefano Stabellini 2017-05-16 19:19 ` Stefano Stabellini 2017-05-16 19:21 ` [Qemu-devel] [PULL 1/4] xen/mapcache: store dma information in revmapcache entries for debugging Stefano Stabellini 2017-05-16 19:21 ` Stefano Stabellini 2017-05-16 19:21 ` [Qemu-devel] [PULL 2/4] configure: Remove -lxencall for Xen detection Stefano Stabellini 2017-05-16 19:21 ` Stefano Stabellini 2017-05-16 19:21 ` [Qemu-devel] [PULL 3/4] xen/9pfs: fix two resource leaks on error paths, discovered by Coverity Stefano Stabellini 2017-05-16 19:21 ` Stefano Stabellini 2017-05-16 19:21 ` [Qemu-devel] [PULL 4/4] xen: call qemu_set_cloexec instead of fcntl Stefano Stabellini 2017-05-16 19:21 ` Stefano Stabellini 2017-05-17 13:04 ` [Qemu-devel] [PULL 0/4] please pull xen-20170516-tag Stefan Hajnoczi 2017-05-17 13:04 ` Stefan Hajnoczi
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.