* [PULL 0/3] Xen queue 2020-02-27 @ 2020-02-27 12:16 ` Anthony PERARD 0 siblings, 0 replies; 10+ messages in thread From: Anthony PERARD @ 2020-02-27 12:16 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, xen-devel The following changes since commit db736e0437aa6fd7c1b7e4599c17f9619ab6b837: Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2020-02-25 13:31:16 +0000) are available in the Git repository at: https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20200227 for you to fetch changes up to 5d4c954931ba62661c6a1bc16ce604a012a10007: Memory: Only call ramblock_ptr when needed in qemu_ram_writeback (2020-02-27 11:50:30 +0000) ---------------------------------------------------------------- Xen queue 2020-02-27 * fix for xen-block * fix in exec.c for migration of xen guest * one cleanup patch ---------------------------------------------------------------- Anthony PERARD (1): Memory: Only call ramblock_ptr when needed in qemu_ram_writeback Paul Durrant (1): xen-bus/block: explicitly assign event channels to an AioContext Philippe Mathieu-Daudé (1): hw/xen/xen_pt_load_rom: Remove unused includes exec.c | 4 ++-- hw/block/dataplane/xen-block.c | 20 ++++++++++++++++++-- hw/xen/xen-bus.c | 27 +++++++++++++++++++++++---- hw/xen/xen_pt_load_rom.c | 4 ---- include/hw/xen/xen-bus.h | 5 ++++- 5 files changed, 47 insertions(+), 13 deletions(-) ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Xen-devel] [PULL 0/3] Xen queue 2020-02-27 @ 2020-02-27 12:16 ` Anthony PERARD 0 siblings, 0 replies; 10+ messages in thread From: Anthony PERARD @ 2020-02-27 12:16 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, xen-devel The following changes since commit db736e0437aa6fd7c1b7e4599c17f9619ab6b837: Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2020-02-25 13:31:16 +0000) are available in the Git repository at: https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20200227 for you to fetch changes up to 5d4c954931ba62661c6a1bc16ce604a012a10007: Memory: Only call ramblock_ptr when needed in qemu_ram_writeback (2020-02-27 11:50:30 +0000) ---------------------------------------------------------------- Xen queue 2020-02-27 * fix for xen-block * fix in exec.c for migration of xen guest * one cleanup patch ---------------------------------------------------------------- Anthony PERARD (1): Memory: Only call ramblock_ptr when needed in qemu_ram_writeback Paul Durrant (1): xen-bus/block: explicitly assign event channels to an AioContext Philippe Mathieu-Daudé (1): hw/xen/xen_pt_load_rom: Remove unused includes exec.c | 4 ++-- hw/block/dataplane/xen-block.c | 20 ++++++++++++++++++-- hw/xen/xen-bus.c | 27 +++++++++++++++++++++++---- hw/xen/xen_pt_load_rom.c | 4 ---- include/hw/xen/xen-bus.h | 5 ++++- 5 files changed, 47 insertions(+), 13 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PULL 1/3] hw/xen/xen_pt_load_rom: Remove unused includes 2020-02-27 12:16 ` [Xen-devel] " Anthony PERARD @ 2020-02-27 12:16 ` Anthony PERARD -1 siblings, 0 replies; 10+ messages in thread From: Anthony PERARD @ 2020-02-27 12:16 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, xen-devel From: Philippe Mathieu-Daudé <philmd@redhat.com> xen_pt_load_rom.c does not use any of these includes, remove them. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20191014142246.4538-9-philmd@redhat.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- hw/xen/xen_pt_load_rom.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c index 307a5c93e235..a50a80837ea2 100644 --- a/hw/xen/xen_pt_load_rom.c +++ b/hw/xen/xen_pt_load_rom.c @@ -3,12 +3,8 @@ */ #include "qemu/osdep.h" #include "qapi/error.h" -#include "hw/i386/pc.h" #include "qemu/error-report.h" -#include "ui/console.h" #include "hw/loader.h" -#include "monitor/monitor.h" -#include "qemu/range.h" #include "hw/pci/pci.h" #include "xen_pt.h" -- Anthony PERARD ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [Xen-devel] [PULL 1/3] hw/xen/xen_pt_load_rom: Remove unused includes @ 2020-02-27 12:16 ` Anthony PERARD 0 siblings, 0 replies; 10+ messages in thread From: Anthony PERARD @ 2020-02-27 12:16 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, xen-devel From: Philippe Mathieu-Daudé <philmd@redhat.com> xen_pt_load_rom.c does not use any of these includes, remove them. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20191014142246.4538-9-philmd@redhat.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- hw/xen/xen_pt_load_rom.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c index 307a5c93e235..a50a80837ea2 100644 --- a/hw/xen/xen_pt_load_rom.c +++ b/hw/xen/xen_pt_load_rom.c @@ -3,12 +3,8 @@ */ #include "qemu/osdep.h" #include "qapi/error.h" -#include "hw/i386/pc.h" #include "qemu/error-report.h" -#include "ui/console.h" #include "hw/loader.h" -#include "monitor/monitor.h" -#include "qemu/range.h" #include "hw/pci/pci.h" #include "xen_pt.h" -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PULL 2/3] xen-bus/block: explicitly assign event channels to an AioContext 2020-02-27 12:16 ` [Xen-devel] " Anthony PERARD @ 2020-02-27 12:16 ` Anthony PERARD -1 siblings, 0 replies; 10+ messages in thread From: Anthony PERARD @ 2020-02-27 12:16 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, xen-devel From: Paul Durrant <pdurrant@amazon.com> It is not safe to close an event channel from the QEMU main thread when that channel's poller is running in IOThread context. This patch adds a new xen_device_set_event_channel_context() function to explicitly assign the channel AioContext, and modifies xen_device_bind_event_channel() to initially assign the channel's poller to the QEMU main thread context. The code in xen-block's dataplane is then modified to assign the channel to IOThread context during xen_block_dataplane_start() and de-assign it during in xen_block_dataplane_stop(), such that the channel is always assigned back to main thread context before it is closed. aio_set_fd_handler() already deals with all the necessary synchronization when moving an fd between AioContext-s so no extra code is needed to manage this. Reported-by: Julien Grall <jgrall@amazon.com> Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20191216143451.19024-1-pdurrant@amazon.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- hw/block/dataplane/xen-block.c | 20 ++++++++++++++++++-- hw/xen/xen-bus.c | 27 +++++++++++++++++++++++---- include/hw/xen/xen-bus.h | 5 ++++- 3 files changed, 45 insertions(+), 7 deletions(-) diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c index 3b9caeb2fa00..288a87a814ad 100644 --- a/hw/block/dataplane/xen-block.c +++ b/hw/block/dataplane/xen-block.c @@ -685,12 +685,24 @@ void xen_block_dataplane_stop(XenBlockDataPlane *dataplane) return; } + xendev = dataplane->xendev; + aio_context_acquire(dataplane->ctx); + if (dataplane->event_channel) { + /* Only reason for failure is a NULL channel */ + xen_device_set_event_channel_context(xendev, dataplane->event_channel, + qemu_get_aio_context(), + &error_abort); + } /* Xen doesn't have multiple users for nodes, so this can't fail */ blk_set_aio_context(dataplane->blk, qemu_get_aio_context(), &error_abort); aio_context_release(dataplane->ctx); - xendev = dataplane->xendev; + /* + * Now that the context has been moved onto the main thread, cancel + * further processing. + */ + qemu_bh_cancel(dataplane->bh); if (dataplane->event_channel) { Error *local_err = NULL; @@ -807,7 +819,7 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane, } dataplane->event_channel = - xen_device_bind_event_channel(xendev, dataplane->ctx, event_channel, + xen_device_bind_event_channel(xendev, event_channel, xen_block_dataplane_event, dataplane, &local_err); if (local_err) { @@ -818,7 +830,11 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane, aio_context_acquire(dataplane->ctx); /* If other users keep the BlockBackend in the iothread, that's ok */ blk_set_aio_context(dataplane->blk, dataplane->ctx, NULL); + /* Only reason for failure is a NULL channel */ + xen_device_set_event_channel_context(xendev, dataplane->event_channel, + dataplane->ctx, &error_abort); aio_context_release(dataplane->ctx); + return; stop: diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c index 919e66162a45..18237b34ea85 100644 --- a/hw/xen/xen-bus.c +++ b/hw/xen/xen-bus.c @@ -1089,8 +1089,26 @@ static void xen_device_event(void *opaque) } } +void xen_device_set_event_channel_context(XenDevice *xendev, + XenEventChannel *channel, + AioContext *ctx, + Error **errp) +{ + if (!channel) { + error_setg(errp, "bad channel"); + return; + } + + if (channel->ctx) + aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), true, + NULL, NULL, NULL, NULL); + + channel->ctx = ctx; + aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), true, + xen_device_event, NULL, xen_device_poll, channel); +} + XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev, - AioContext *ctx, unsigned int port, XenEventHandler handler, void *opaque, Error **errp) @@ -1116,9 +1134,10 @@ XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev, channel->handler = handler; channel->opaque = opaque; - channel->ctx = ctx; - aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), true, - xen_device_event, NULL, xen_device_poll, channel); + /* Only reason for failure is a NULL channel */ + xen_device_set_event_channel_context(xendev, channel, + qemu_get_aio_context(), + &error_abort); QLIST_INSERT_HEAD(&xendev->event_channels, channel, list); diff --git a/include/hw/xen/xen-bus.h b/include/hw/xen/xen-bus.h index 3d5532258df7..c18c1372af38 100644 --- a/include/hw/xen/xen-bus.h +++ b/include/hw/xen/xen-bus.h @@ -128,10 +128,13 @@ void xen_device_copy_grant_refs(XenDevice *xendev, bool to_domain, typedef bool (*XenEventHandler)(void *opaque); XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev, - AioContext *ctx, unsigned int port, XenEventHandler handler, void *opaque, Error **errp); +void xen_device_set_event_channel_context(XenDevice *xendev, + XenEventChannel *channel, + AioContext *ctx, + Error **errp); void xen_device_notify_event_channel(XenDevice *xendev, XenEventChannel *channel, Error **errp); -- Anthony PERARD ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [Xen-devel] [PULL 2/3] xen-bus/block: explicitly assign event channels to an AioContext @ 2020-02-27 12:16 ` Anthony PERARD 0 siblings, 0 replies; 10+ messages in thread From: Anthony PERARD @ 2020-02-27 12:16 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, xen-devel From: Paul Durrant <pdurrant@amazon.com> It is not safe to close an event channel from the QEMU main thread when that channel's poller is running in IOThread context. This patch adds a new xen_device_set_event_channel_context() function to explicitly assign the channel AioContext, and modifies xen_device_bind_event_channel() to initially assign the channel's poller to the QEMU main thread context. The code in xen-block's dataplane is then modified to assign the channel to IOThread context during xen_block_dataplane_start() and de-assign it during in xen_block_dataplane_stop(), such that the channel is always assigned back to main thread context before it is closed. aio_set_fd_handler() already deals with all the necessary synchronization when moving an fd between AioContext-s so no extra code is needed to manage this. Reported-by: Julien Grall <jgrall@amazon.com> Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20191216143451.19024-1-pdurrant@amazon.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- hw/block/dataplane/xen-block.c | 20 ++++++++++++++++++-- hw/xen/xen-bus.c | 27 +++++++++++++++++++++++---- include/hw/xen/xen-bus.h | 5 ++++- 3 files changed, 45 insertions(+), 7 deletions(-) diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c index 3b9caeb2fa00..288a87a814ad 100644 --- a/hw/block/dataplane/xen-block.c +++ b/hw/block/dataplane/xen-block.c @@ -685,12 +685,24 @@ void xen_block_dataplane_stop(XenBlockDataPlane *dataplane) return; } + xendev = dataplane->xendev; + aio_context_acquire(dataplane->ctx); + if (dataplane->event_channel) { + /* Only reason for failure is a NULL channel */ + xen_device_set_event_channel_context(xendev, dataplane->event_channel, + qemu_get_aio_context(), + &error_abort); + } /* Xen doesn't have multiple users for nodes, so this can't fail */ blk_set_aio_context(dataplane->blk, qemu_get_aio_context(), &error_abort); aio_context_release(dataplane->ctx); - xendev = dataplane->xendev; + /* + * Now that the context has been moved onto the main thread, cancel + * further processing. + */ + qemu_bh_cancel(dataplane->bh); if (dataplane->event_channel) { Error *local_err = NULL; @@ -807,7 +819,7 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane, } dataplane->event_channel = - xen_device_bind_event_channel(xendev, dataplane->ctx, event_channel, + xen_device_bind_event_channel(xendev, event_channel, xen_block_dataplane_event, dataplane, &local_err); if (local_err) { @@ -818,7 +830,11 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane, aio_context_acquire(dataplane->ctx); /* If other users keep the BlockBackend in the iothread, that's ok */ blk_set_aio_context(dataplane->blk, dataplane->ctx, NULL); + /* Only reason for failure is a NULL channel */ + xen_device_set_event_channel_context(xendev, dataplane->event_channel, + dataplane->ctx, &error_abort); aio_context_release(dataplane->ctx); + return; stop: diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c index 919e66162a45..18237b34ea85 100644 --- a/hw/xen/xen-bus.c +++ b/hw/xen/xen-bus.c @@ -1089,8 +1089,26 @@ static void xen_device_event(void *opaque) } } +void xen_device_set_event_channel_context(XenDevice *xendev, + XenEventChannel *channel, + AioContext *ctx, + Error **errp) +{ + if (!channel) { + error_setg(errp, "bad channel"); + return; + } + + if (channel->ctx) + aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), true, + NULL, NULL, NULL, NULL); + + channel->ctx = ctx; + aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), true, + xen_device_event, NULL, xen_device_poll, channel); +} + XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev, - AioContext *ctx, unsigned int port, XenEventHandler handler, void *opaque, Error **errp) @@ -1116,9 +1134,10 @@ XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev, channel->handler = handler; channel->opaque = opaque; - channel->ctx = ctx; - aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), true, - xen_device_event, NULL, xen_device_poll, channel); + /* Only reason for failure is a NULL channel */ + xen_device_set_event_channel_context(xendev, channel, + qemu_get_aio_context(), + &error_abort); QLIST_INSERT_HEAD(&xendev->event_channels, channel, list); diff --git a/include/hw/xen/xen-bus.h b/include/hw/xen/xen-bus.h index 3d5532258df7..c18c1372af38 100644 --- a/include/hw/xen/xen-bus.h +++ b/include/hw/xen/xen-bus.h @@ -128,10 +128,13 @@ void xen_device_copy_grant_refs(XenDevice *xendev, bool to_domain, typedef bool (*XenEventHandler)(void *opaque); XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev, - AioContext *ctx, unsigned int port, XenEventHandler handler, void *opaque, Error **errp); +void xen_device_set_event_channel_context(XenDevice *xendev, + XenEventChannel *channel, + AioContext *ctx, + Error **errp); void xen_device_notify_event_channel(XenDevice *xendev, XenEventChannel *channel, Error **errp); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PULL 3/3] Memory: Only call ramblock_ptr when needed in qemu_ram_writeback 2020-02-27 12:16 ` [Xen-devel] " Anthony PERARD @ 2020-02-27 12:16 ` Anthony PERARD -1 siblings, 0 replies; 10+ messages in thread From: Anthony PERARD @ 2020-02-27 12:16 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, xen-devel It is possible that a ramblock doesn't have memory that QEMU can access, this is the case with the Xen hypervisor. In order to avoid to trigger an assert, only call ramblock_ptr() when needed in qemu_ram_writeback(). This should fix migration of Xen guests that was broken with bd108a44bc29 ("migration: ram: Switch to ram block writeback"). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20191219154323.325255-1-anthony.perard@citrix.com> --- exec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/exec.c b/exec.c index 231d6e564109..0cc500d53a23 100644 --- a/exec.c +++ b/exec.c @@ -2116,14 +2116,13 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp) */ void qemu_ram_writeback(RAMBlock *block, ram_addr_t start, ram_addr_t length) { - void *addr = ramblock_ptr(block, start); - /* The requested range should fit in within the block range */ g_assert((start + length) <= block->used_length); #ifdef CONFIG_LIBPMEM /* The lack of support for pmem should not block the sync */ if (ramblock_is_pmem(block)) { + void *addr = ramblock_ptr(block, start); pmem_persist(addr, length); return; } @@ -2134,6 +2133,7 @@ void qemu_ram_writeback(RAMBlock *block, ram_addr_t start, ram_addr_t length) * specified as persistent (or is not one) - use the msync. * Less optimal but still achieves the same goal */ + void *addr = ramblock_ptr(block, start); if (qemu_msync(addr, length, block->fd)) { warn_report("%s: failed to sync memory range: start: " RAM_ADDR_FMT " length: " RAM_ADDR_FMT, -- Anthony PERARD ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [Xen-devel] [PULL 3/3] Memory: Only call ramblock_ptr when needed in qemu_ram_writeback @ 2020-02-27 12:16 ` Anthony PERARD 0 siblings, 0 replies; 10+ messages in thread From: Anthony PERARD @ 2020-02-27 12:16 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, xen-devel It is possible that a ramblock doesn't have memory that QEMU can access, this is the case with the Xen hypervisor. In order to avoid to trigger an assert, only call ramblock_ptr() when needed in qemu_ram_writeback(). This should fix migration of Xen guests that was broken with bd108a44bc29 ("migration: ram: Switch to ram block writeback"). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20191219154323.325255-1-anthony.perard@citrix.com> --- exec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/exec.c b/exec.c index 231d6e564109..0cc500d53a23 100644 --- a/exec.c +++ b/exec.c @@ -2116,14 +2116,13 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp) */ void qemu_ram_writeback(RAMBlock *block, ram_addr_t start, ram_addr_t length) { - void *addr = ramblock_ptr(block, start); - /* The requested range should fit in within the block range */ g_assert((start + length) <= block->used_length); #ifdef CONFIG_LIBPMEM /* The lack of support for pmem should not block the sync */ if (ramblock_is_pmem(block)) { + void *addr = ramblock_ptr(block, start); pmem_persist(addr, length); return; } @@ -2134,6 +2133,7 @@ void qemu_ram_writeback(RAMBlock *block, ram_addr_t start, ram_addr_t length) * specified as persistent (or is not one) - use the msync. * Less optimal but still achieves the same goal */ + void *addr = ramblock_ptr(block, start); if (qemu_msync(addr, length, block->fd)) { warn_report("%s: failed to sync memory range: start: " RAM_ADDR_FMT " length: " RAM_ADDR_FMT, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PULL 0/3] Xen queue 2020-02-27 2020-02-27 12:16 ` [Xen-devel] " Anthony PERARD @ 2020-02-28 11:19 ` Peter Maydell -1 siblings, 0 replies; 10+ messages in thread From: Peter Maydell @ 2020-02-28 11:19 UTC (permalink / raw) To: Anthony PERARD; +Cc: open list:X86, QEMU Developers On Thu, 27 Feb 2020 at 12:16, Anthony PERARD <anthony.perard@citrix.com> wrote: > > The following changes since commit db736e0437aa6fd7c1b7e4599c17f9619ab6b837: > > Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2020-02-25 13:31:16 +0000) > > are available in the Git repository at: > > https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20200227 > > for you to fetch changes up to 5d4c954931ba62661c6a1bc16ce604a012a10007: > > Memory: Only call ramblock_ptr when needed in qemu_ram_writeback (2020-02-27 11:50:30 +0000) > > ---------------------------------------------------------------- > Xen queue 2020-02-27 > > * fix for xen-block > * fix in exec.c for migration of xen guest > * one cleanup patch > > ---------------------------------------------------------------- Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.0 for any user-visible changes. -- PMM ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xen-devel] [PULL 0/3] Xen queue 2020-02-27 @ 2020-02-28 11:19 ` Peter Maydell 0 siblings, 0 replies; 10+ messages in thread From: Peter Maydell @ 2020-02-28 11:19 UTC (permalink / raw) To: Anthony PERARD; +Cc: open list:X86, QEMU Developers On Thu, 27 Feb 2020 at 12:16, Anthony PERARD <anthony.perard@citrix.com> wrote: > > The following changes since commit db736e0437aa6fd7c1b7e4599c17f9619ab6b837: > > Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2020-02-25 13:31:16 +0000) > > are available in the Git repository at: > > https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20200227 > > for you to fetch changes up to 5d4c954931ba62661c6a1bc16ce604a012a10007: > > Memory: Only call ramblock_ptr when needed in qemu_ram_writeback (2020-02-27 11:50:30 +0000) > > ---------------------------------------------------------------- > Xen queue 2020-02-27 > > * fix for xen-block > * fix in exec.c for migration of xen guest > * one cleanup patch > > ---------------------------------------------------------------- Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.0 for any user-visible changes. -- PMM _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-02-28 11:20 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-27 12:16 [PULL 0/3] Xen queue 2020-02-27 Anthony PERARD 2020-02-27 12:16 ` [Xen-devel] " Anthony PERARD 2020-02-27 12:16 ` [PULL 1/3] hw/xen/xen_pt_load_rom: Remove unused includes Anthony PERARD 2020-02-27 12:16 ` [Xen-devel] " Anthony PERARD 2020-02-27 12:16 ` [PULL 2/3] xen-bus/block: explicitly assign event channels to an AioContext Anthony PERARD 2020-02-27 12:16 ` [Xen-devel] " Anthony PERARD 2020-02-27 12:16 ` [PULL 3/3] Memory: Only call ramblock_ptr when needed in qemu_ram_writeback Anthony PERARD 2020-02-27 12:16 ` [Xen-devel] " Anthony PERARD 2020-02-28 11:19 ` [PULL 0/3] Xen queue 2020-02-27 Peter Maydell 2020-02-28 11:19 ` [Xen-devel] " Peter Maydell
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.