On 17.07.2024 22:19, Fabiano Rosas wrote:
Peter Xu writes:
On Tue, Jul 16, 2024 at 10:10:12PM +0200, Maciej S. Szmigiero wrote:
On 27.06.2024 16:56, Peter Xu wrote:
On Thu, Jun 27, 2024 at 11:14:28AM +0200, Maciej S. Szmigiero wrote:
On 26.06.2024 18:23, Peter Xu wrote:
On Wed, Jun 26
On 17.07.2024 21:00, Peter Xu wrote:
On Tue, Jul 16, 2024 at 10:10:25PM +0200, Maciej S. Szmigiero wrote:
The comment I removed is slightly misleading to me too, because right now
active_slot contains the data hasn't yet been delivered to multifd, so
we're "putting it back to free
On 10.07.2024 22:16, Fabiano Rosas wrote:
Peter Xu writes:
On Wed, Jul 10, 2024 at 01:10:37PM -0300, Fabiano Rosas wrote:
Peter Xu writes:
On Thu, Jun 27, 2024 at 11:27:08AM +0800, Wang, Lei wrote:
Or graphically:
1) client fills the active slot with data. Channels point to nothing
On 27.06.2024 16:56, Peter Xu wrote:
On Thu, Jun 27, 2024 at 11:14:28AM +0200, Maciej S. Szmigiero wrote:
On 26.06.2024 18:23, Peter Xu wrote:
On Wed, Jun 26, 2024 at 05:47:34PM +0200, Maciej S. Szmigiero wrote:
On 26.06.2024 03:51, Peter Xu wrote:
On Wed, Jun 26, 2024 at 12:44:29AM +0200
On 26.06.2024 18:23, Peter Xu wrote:
On Wed, Jun 26, 2024 at 05:47:34PM +0200, Maciej S. Szmigiero wrote:
On 26.06.2024 03:51, Peter Xu wrote:
On Wed, Jun 26, 2024 at 12:44:29AM +0200, Maciej S. Szmigiero wrote:
On 25.06.2024 19:25, Peter Xu wrote:
On Mon, Jun 24, 2024 at 09:51:18PM +0200
On 26.06.2024 03:51, Peter Xu wrote:
On Wed, Jun 26, 2024 at 12:44:29AM +0200, Maciej S. Szmigiero wrote:
On 25.06.2024 19:25, Peter Xu wrote:
On Mon, Jun 24, 2024 at 09:51:18PM +0200, Maciej S. Szmigiero wrote:
Hi Peter,
Hi, Maciej,
On 23.06.2024 22:27, Peter Xu wrote:
On Tue, Jun 18
On 25.06.2024 19:25, Peter Xu wrote:
On Mon, Jun 24, 2024 at 09:51:18PM +0200, Maciej S. Szmigiero wrote:
Hi Peter,
Hi, Maciej,
On 23.06.2024 22:27, Peter Xu wrote:
On Tue, Jun 18, 2024 at 06:12:18PM +0200, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This is an
Hi Peter,
On 23.06.2024 22:27, Peter Xu wrote:
On Tue, Jun 18, 2024 at 06:12:18PM +0200, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This is an updated v1 patch series of the RFC (v0) series located here:
https://lore.kernel.org/qemu-devel/cover.1713269378.git.mac
On 21.06.2024 22:54, Peter Xu wrote:
On Fri, Jun 21, 2024 at 07:40:01PM +0200, Maciej S. Szmigiero wrote:
On 21.06.2024 17:56, Peter Xu wrote:
On Fri, Jun 21, 2024 at 05:31:54PM +0200, Maciej S. Szmigiero wrote:
On 21.06.2024 17:04, Fabiano Rosas wrote:
"Maciej S. Szmigiero" wr
On 21.06.2024 17:56, Peter Xu wrote:
On Fri, Jun 21, 2024 at 05:31:54PM +0200, Maciej S. Szmigiero wrote:
On 21.06.2024 17:04, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
Hi Fabiano,
On 20.06.2024 23:21, Fabiano Rosas wrote:
Hi folks,
First of all, apologies for the
On 21.06.2024 17:04, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
Hi Fabiano,
On 20.06.2024 23:21, Fabiano Rosas wrote:
Hi folks,
First of all, apologies for the roughness of the series. I'm off for
the next couple of weeks and wanted to put something together earl
Hi Fabiano,
On 20.06.2024 23:21, Fabiano Rosas wrote:
Hi folks,
First of all, apologies for the roughness of the series. I'm off for
the next couple of weeks and wanted to put something together early
for your consideration.
This series is a refactoring (based on an earlier, off-list
From: "Maciej S. Szmigiero"
This is an updated v1 patch series of the RFC (v0) series located here:
https://lore.kernel.org/qemu-devel/cover.1713269378.git.maciej.szmigi...@oracle.com/
Changes from the RFC (v0):
* Extend the existing multifd packet format instead of introducing a new
From: "Maciej S. Szmigiero"
There's a RAM load complete trace event but there wasn't its start equivalent.
Signed-off-by: Maciej S. Szmigiero
---
migration/ram.c| 1 +
migration/trace-events | 1 +
2 files changed, 2 insertions(+)
diff --git a/migration/ram.c b/migration/r
From: "Maciej S. Szmigiero"
This is necessary for multifd_send_pages() to be able to be called
from multiple threads.
Signed-off-by: Maciej S. Szmigiero
---
migration/multifd.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/migration/m
From: "Maciej S. Szmigiero"
load_finish SaveVMHandler allows migration code to poll whether
a device-specific asynchronous device state loading operation had finished.
In order to avoid calling this handler needlessly the device is supposed
to notify the migration code of its possible
From: "Maciej S. Szmigiero"
qemu_loadvm_load_state_buffer() and its load_state_buffer
SaveVMHandler allow providing device state buffer to explicitly
specified device via its idstr and instance id.
Signed-off-by: Maciej S. Szmigiero
---
include/migration/regis
From: "Maciej S. Szmigiero"
Add a basic support for receiving device state via multifd channels -
channels that are shared with RAM transfers.
To differentiate between a device state and a RAM packet the packet
header is read first.
Depending whether MULTIFD_FLAG_DEVICE_STATE flag
From: "Maciej S. Szmigiero"
This way there aren't stale flags there.
p->flags can't contain SYNC to be sent at the next RAM packet since syncs
are now handled separately in multifd_send_thread.
Signed-off-by: Maciej S. Szmigiero
---
migration/multifd.c | 2 +-
1 file changed
From: "Maciej S. Szmigiero"
This way both the start and end points of migrating a particular VFIO
device are known.
Add also a vfio_save_iterate_empty_hit trace event so it is known when
there's no more data to send for that device.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/m
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thread spawned from save_live_complete_precopy_begin handler.
Switch between doing the data transfer in the new handler and doing it
in the old save_state handler depending on the
x
From: "Maciej S. Szmigiero"
This property allows configuring at runtime whether to send the
particular device state via multifd channels when live migrating that
device.
It is ignored on the receive side and defaults to "false" for bit stream
compatibility with older QEMU v
From: "Maciej S. Szmigiero"
The multifd received data needs to be reassembled since device state
packets sent via different multifd channels can arrive out-of-order.
Therefore, each VFIO device state packet carries a header indicating
its position in the stream.
The last such VFIO de
From: "Maciej S. Szmigiero"
A new function multifd_queue_device_state() is provided for device to queue
its state for transmission via a multifd channel.
Signed-off-by: Maciej S. Szmigiero
---
include/migration/misc.h | 4 +
migration/multifd-zlib.c | 2 +-
migration/multifd-zs
From: "Maciej S. Szmigiero"
These SaveVMHandlers allow device to provide its own asynchronous
transmission of the remaining data at the end of a precopy phase.
In this use case the save_live_complete_precopy_begin handler is
supposed to start such transmission (for example, by
From: "Maciej S. Szmigiero"
Since device state transfer via multifd channels requires multifd
channels with packets and is currently not compatible with multifd
compression add an appropriate query function so device can learn
whether it can actually make use of it.
Signed-off-by
On 29.04.2024 17:09, Peter Xu wrote:
On Fri, Apr 26, 2024 at 07:34:09PM +0200, Maciej S. Szmigiero wrote:
On 24.04.2024 00:35, Peter Xu wrote:
On Wed, Apr 24, 2024 at 12:25:08AM +0200, Maciej S. Szmigiero wrote:
On 24.04.2024 00:20, Peter Xu wrote:
On Tue, Apr 23, 2024 at 06:15:35PM +0200
On 29.04.2024 22:04, Peter Xu wrote:
On Tue, Apr 16, 2024 at 04:43:02PM +0200, Maciej S. Szmigiero wrote:
+bool multifd_queue_page(RAMBlock *block, ram_addr_t offset)
+{
+g_autoptr(GMutexLocker) locker = NULL;
+
+/*
+ * Device state submissions for shared channels can come
On 24.04.2024 00:27, Peter Xu wrote:
On Tue, Apr 23, 2024 at 06:14:18PM +0200, Maciej S. Szmigiero wrote:
We don't lose any genericity since by default the transfer is done via
mixed RAM / device state multifd channels from a shared pool.
It's only when x-multifd-channels-device-state is set
On 24.04.2024 00:35, Peter Xu wrote:
On Wed, Apr 24, 2024 at 12:25:08AM +0200, Maciej S. Szmigiero wrote:
On 24.04.2024 00:20, Peter Xu wrote:
On Tue, Apr 23, 2024 at 06:15:35PM +0200, Maciej S. Szmigiero wrote:
On 19.04.2024 17:31, Peter Xu wrote:
On Fri, Apr 19, 2024 at 11:07:21AM +0100
On 24.04.2024 00:20, Peter Xu wrote:
On Tue, Apr 23, 2024 at 06:15:35PM +0200, Maciej S. Szmigiero wrote:
On 19.04.2024 17:31, Peter Xu wrote:
On Fri, Apr 19, 2024 at 11:07:21AM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 18, 2024 at 04:02:49PM -0400, Peter Xu wrote:
On Thu, Apr 18, 2024
On 19.04.2024 17:31, Peter Xu wrote:
On Fri, Apr 19, 2024 at 11:07:21AM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 18, 2024 at 04:02:49PM -0400, Peter Xu wrote:
On Thu, Apr 18, 2024 at 08:14:15PM +0200, Maciej S. Szmigiero wrote:
I think one of the reasons for these results is that mixed
On 18.04.2024 22:02, Peter Xu wrote:
On Thu, Apr 18, 2024 at 08:14:15PM +0200, Maciej S. Szmigiero wrote:
On 18.04.2024 12:39, Daniel P. Berrangé wrote:
On Thu, Apr 18, 2024 at 11:50:12AM +0200, Maciej S. Szmigiero wrote:
On 17.04.2024 18:35, Daniel P. Berrangé wrote:
On Wed, Apr 17, 2024
On 18.04.2024 12:39, Daniel P. Berrangé wrote:
On Thu, Apr 18, 2024 at 11:50:12AM +0200, Maciej S. Szmigiero wrote:
On 17.04.2024 18:35, Daniel P. Berrangé wrote:
On Wed, Apr 17, 2024 at 02:11:37PM +0200, Maciej S. Szmigiero wrote:
On 17.04.2024 10:36, Daniel P. Berrangé wrote:
On Tue, Apr
On 17.04.2024 18:35, Daniel P. Berrangé wrote:
On Wed, Apr 17, 2024 at 02:11:37PM +0200, Maciej S. Szmigiero wrote:
On 17.04.2024 10:36, Daniel P. Berrangé wrote:
On Tue, Apr 16, 2024 at 04:42:39PM +0200, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
VFIO device stat
On 17.04.2024 10:36, Daniel P. Berrangé wrote:
On Tue, Apr 16, 2024 at 04:42:39PM +0200, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
VFIO device state transfer is currently done via the main migration channel.
This means that transfers from multiple VFIO device
From: "Maciej S. Szmigiero"
load_finish SaveVMHandler allows migration code to poll whether
a device-specific asynchronous device state loading operation had finished.
In order to avoid calling this handler needlessly the device is supposed
to notify the migration code of its possible
From: "Maciej S. Szmigiero"
This will allow passing additional parameters there in the future.
Signed-off-by: Maciej S. Szmigiero
---
migration/postcopy-ram.c | 68 +++-
1 file changed, 61 insertions(+), 7 deletions(-)
diff --git a/migration/post
From: "Maciej S. Szmigiero"
Since device state transfer via multifd channels requires multifd
channels with migration channel header and is currently not compatible
with multifd compression add an appropriate query function so device
can learn whether it can actually make use of it.
From: "Maciej S. Szmigiero"
This way there aren't stale flags there.
p->flags can't contain SYNC to be sent at the next RAM packet since syncs
are now handled separately in multifd_send_thread.
Signed-off-by: Maciej S. Szmigiero
---
migration/multifd.c | 2 +-
1 file changed
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thread spawned from save_live_complete_precopy_async handler.
Switch between doing the data transfer in the new handler and doing it
in the old save_state handler
From: "Maciej S. Szmigiero"
This parameter allows specifying how many multifd channels are dedicated
to sending device state in parallel.
It is ignored on the receive side.
Signed-off-by: Maciej S. Szmigiero
---
migration/migration-hmp-cmds.c | 7 +
migration/options.c
From: "Maciej S. Szmigiero"
This is necessary for multifd_send_pages() to be able to be called
from multiple threads.
Signed-off-by: Maciej S. Szmigiero
---
migration/multifd.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/migration/multifd.c b/migration
From: "Maciej S. Szmigiero"
A new function multifd_queue_device_state() is provided for device to queue
its state for transmission via a multifd channel.
Signed-off-by: Maciej S. Szmigiero
---
include/migration/misc.h | 4 +
migration/multifd-zlib.c | 2 +-
migration/multifd-zs
From: Avihai Horon
Signed-off-by: Avihai Horon
[MSS: Rewrite using MFDSendChannelConnectData/PostcopyPChannelConnectData]
Signed-off-by: Maciej S. Szmigiero
---
migration/multifd.c | 14 --
migration/postcopy-ram.c | 14 --
2 files changed, 24 insertions(+), 4
From: "Maciej S. Szmigiero"
Signed-off-by: Maciej S. Szmigiero
---
migration/channel.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/migration/channel.h b/migration/channel.h
index 4232ee649939..b985c952550d 100644
--- a/migration/channel.h
+++ b/migration/channel.h
@@ -
From: Avihai Horon
Add functions to send and receive migration channel header.
Signed-off-by: Avihai Horon
[MSS: Mark MigChannelHeader as packed, remove device id from it]
Signed-off-by: Maciej S. Szmigiero
---
migration/channel.c| 59 ++
migration
From: "Maciej S. Szmigiero"
Add a basic support for receiving device state via multifd channels -
both dedicated ones or shared with RAM transfer.
To differentiate between a device state and a RAM packet the packet
header is read first.
Depending whether MULTIFD_FLAG_DEVICE_
From: "Maciej S. Szmigiero"
There's a RAM load complete trace event but there wasn't its start equivalent.
Signed-off-by: Maciej S. Szmigiero
---
migration/ram.c| 1 +
migration/trace-events | 1 +
2 files changed, 2 insertions(+)
diff --git a/migration/ram.c b/migration/r
From: "Maciej S. Szmigiero"
VFIO device state transfer is currently done via the main migration channel.
This means that transfers from multiple VFIO devices are done sequentially
and via just a single common migration channel.
Such way of transferring VFIO device state migration da
From: Avihai Horon
Now that migration channel header has been implemented, enable it.
Signed-off-by: Avihai Horon
Signed-off-by: Maciej S. Szmigiero
---
migration/options.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/migration/options.c b/migration/options.c
index abb5b485badd
From: Avihai Horon
Add send and receive migration channel header for postcopy preempt
channel.
Signed-off-by: Avihai Horon
[MSS: Adapt to rewritten migration header passing commit]
Signed-off-by: Maciej S. Szmigiero
---
migration/channel.h | 1 +
migration/migration.c| 5
From: "Maciej S. Szmigiero"
These SaveVMHandlers allow device to provide its own asynchronous
transmission of the remaining data at the end of a precopy phase.
The save_live_complete_precopy_async handler is supposed to start such
transmission (for example, by launching appropria
From: "Maciej S. Szmigiero"
The multifd received data needs to be reassembled since device state
packets sent via different multifd channels can arrive out-of-order.
Therefore, each VFIO device state packet carries a header indicating
its position in the stream.
The last such VFIO de
From: Avihai Horon
Add send and receive migration channel header for multifd channel.
Signed-off-by: Avihai Horon
[MSS: Adapt to rewritten migration header passing commit]
Signed-off-by: Maciej S. Szmigiero
---
migration/channel.h | 1 +
migration/migration.c | 16
From: "Maciej S. Szmigiero"
Mapped-ram is only available for multifd migration without channel
header - add an appropriate check to migration options.
Signed-off-by: Maciej S. Szmigiero
---
migration/options.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/migration/o
From: "Maciej S. Szmigiero"
qemu_loadvm_load_state_buffer() and its load_state_buffer
SaveVMHandler allow providing device state buffer to explicitly
specified device via its idstr and instance id.
Signed-off-by: Maciej S. Szmigiero
---
include/migration/regis
.
The following patches will add the actual functionality, after which it
will be enabled..
Signed-off-by: Avihai Horon
Signed-off-by: Maciej S. Szmigiero
---
hw/core/machine.c | 1 +
migration/migration.h | 3 +++
migration/options.c | 9 +
migration/options.h | 1 +
4 files changed
From: "Maciej S. Szmigiero"
This way both the start and end points of migrating a particular VFIO
device are known.
Add also a vfio_save_iterate_empty_hit trace event so it is known when
there's no more data to send for that device.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/m
From: "Maciej S. Szmigiero"
This function is called only with MultiFDSendParams type param so use this
type explicitly instead of using an opaque pointer.
Signed-off-by: Maciej S. Szmigiero
---
migration/multifd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: "Maciej S. Szmigiero"
This will allow passing additional parameters there in the future.
Signed-off-by: Maciej S. Szmigiero
---
migration/file.c| 5 ++-
migration/multifd.c | 95 ++---
migration/multifd.h | 4 +-
3 files c
From: Avihai Horon
Add send and receive migration channel header for main channel.
Signed-off-by: Avihai Horon
[MSS: Rename main channel -> default channel where it matches the current term]
Signed-off-by: Maciej S. Szmigiero
---
migration/channel.c | 9 +
migration/migration.c |
From: "Maciej S. Szmigiero"
Makes managing the memory easier.
Signed-off-by: Maciej S. Szmigiero
---
migration/multifd.c | 2 +-
migration/postcopy-ram.c | 2 +-
migration/socket.c | 6 --
migration/socket.h | 3 ++-
4 files changed, 8 insertions(+), 5 deletion
From: "Maciej S. Szmigiero"
alloca() is frowned upon, replace it with g_malloc0() + g_autofree.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/hyperv/hv-balloon.c | 10 --
1 file changed, 4 insertions(+), 6
From: "Maciej S. Szmigiero"
Some Windows versions crash at boot or fail to enable the VMBus device if
they don't see the expected set of Hyper-V features (enlightenments).
Since this provides poor user experience let's warn user if the VMBus
device is enabled without the recom
From: "Maciej S. Szmigiero"
The following changes since commit 8f6330a807f2642dc2a3cdf33347aa28a4c00a87:
Merge tag 'pull-maintainer-updates-060324-1' of
https://gitlab.com/stsquad/qemu into staging (2024-03-06 16:56:20 +)
are available in the Git repository at:
https://
From: "Maciej S. Szmigiero"
Since the presence of a hot add memory region is optional in hot add
request message it wasn't part of this message declaration
(struct dm_hot_add).
Instead, the code allocated such enlarged message by simply adding the
necessary size for this extra field t
On 25.01.2024 17:19, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Some Windows versions crash at boot or fail to enable the VMBus device if
they don't see the expected set of Hyper-V features (enlightenments).
Since this provides poor user experience let's warn user if
From: "Maciej S. Szmigiero"
Some Windows versions crash at boot or fail to enable the VMBus device if
they don't see the expected set of Hyper-V features (enlightenments).
Since this provides poor user experience let's warn user if the VMBus
device is enabled without the recom
that check in the first place.
Cc: "Maciej S. Szmigiero"
Cc: Mario Casquero
Cc: Igor Mammedov
Cc: Xiao Guangrong
David Hildenbrand (2):
hv-balloon: use get_min_alignment() to express 32 GiB alignment
memory-device: reintroduce memory region size check
hw/hyperv/hv-ball
-off-by: Peter Maydell
---
Acked-by: Maciej S. Szmigiero
Thanks,
Maciej
On 14.11.2023 17:58, Michael Tokarev wrote:
Fixes: 4f80cd2f033e "Add Hyper-V Dynamic Memory Protocol definitions"
Cc: Maciej S. Szmigiero
Signed-off-by: Michael Tokarev
---
Acked-by: Maciej S. Szmigiero
Thanks,
Maciej
From: "Maciej S. Szmigiero"
Since the presence of a hot add memory region is optional in hot add
request message it wasn't part of this message declaration
(struct dm_hot_add).
Instead, the code allocated such enlarged message by simply adding the
necessary size for this extra field t
On 13.11.2023 09:59, David Hildenbrand wrote:
On 09.11.23 17:02, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
alloca() is frowned upon, replace it with g_malloc0() + g_autofree.
Reviewed-by: David Hildenbrand
If this fixes a coverity issue of #number, we usuall
From: "Maciej S. Szmigiero"
alloca() is frowned upon, replace it with g_malloc0() + g_autofree.
Signed-off-by: Maciej S. Szmigiero
---
hw/hyperv/hv-balloon.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/hyperv/hv-balloon.c b/hw/hyperv/hv-ballo
On 9.11.2023 15:51, Peter Maydell wrote:
On Mon, 6 Nov 2023 at 14:23, Maciej S. Szmigiero
wrote:
From: "Maciej S. Szmigiero"
One of advantages of using this protocol over ACPI-based PC DIMM hotplug is
that it allows hot-adding memory in much smaller granularity because the
ACPI
From: "Maciej S. Szmigiero"
Acked-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e8a7d5be5de..d4a480ce5a62 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2656,6 +26
From: "Maciej S. Szmigiero"
This commit adds Hyper-V Dynamic Memory Protocol definitions, taken
from hv_balloon Linux kernel driver, adapted to the QEMU coding style and
definitions.
Acked-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
include/hw/hyperv/dynmem-pro
From: "Maciej S. Szmigiero"
This driver is like virtio-balloon on steroids: it allows both changing the
guest memory allocation via ballooning and (in the next patch) inserting
pieces of extra RAM into it on demand from a provided memory backend.
The actual resizing is done via
From: "Maciej S. Szmigiero"
Used by the driver to report its provided memory state information.
Co-developed-by: David Hildenbrand
Reviewed-by: David Hildenbrand
Acked-by: Markus Armbruster
Signed-off-by: Maciej S. Szmigiero
---
hw/core/machine-hmp-cmds.c | 15 +++
hw
From: "Maciej S. Szmigiero"
Hi Stefan,
Fixed the CI pipeline issues with yesterday's pull request, and:
the following changes since commit d762bf97931b58839316b68a570eecc6143c9e3e:
Merge tag 'pull-target-arm-20231102' of
https://git.linaro.org/people/pmaydell/qemu-arm into stagin
From: "Maciej S. Szmigiero"
This reverts commit 5960f254dbb46f0c7a9f5f44bf4d27c19c34cb97 since the
previous commit made this situation possible again.
Signed-off-by: Maciej S. Szmigiero
---
hw/virtio/virtio-pmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
From: "Maciej S. Szmigiero"
One of advantages of using this protocol over ACPI-based PC DIMM hotplug is
that it allows hot-adding memory in much smaller granularity because the
ACPI DIMM slot limit does not apply.
In order to enable this functionality a new memory backend needs to
From: David Hildenbrand
Let's support empty memory devices -- memory devices that don't have a
memory device region in the current configuration. hv-balloon with an
optional memdev is the primary use case.
Signed-off-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/mem/memory
From: "Maciej S. Szmigiero"
Used by the hv-balloon driver for (optional) guest memory status reports.
Acked-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/hyperv/hv-balloon-stub.c | 19
hw/hyperv/hv-balloon.c | 30 +-
hw/hyperv/m
From: "Maciej S. Szmigiero"
Add the necessary plumbing for the hv-balloon driver to the PC machine.
Co-developed-by: David Hildenbrand
Reviewed-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/i386/Kconfig | 1 +
hw/i386/pc.c| 22 ++
2 fil
From: David Hildenbrand
There is no strong requirement that the size has to be multiples of the
requested alignment, let's drop it. This is a preparation for hv-baloon.
Signed-off-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/mem/memory-device.c | 6 --
1 file changed
On 6.11.2023 02:33, Stefan Hajnoczi wrote:
On Sun, 5 Nov 2023 at 19:49, Maciej S. Szmigiero
wrote:
From: "Maciej S. Szmigiero"
The following changes since commit d762bf97931b58839316b68a570eecc6143c9e3e:
Merge tag 'pull-target-arm-20231102' of
https://git.linaro.org/peopl
From: "Maciej S. Szmigiero"
This commit adds Hyper-V Dynamic Memory Protocol definitions, taken
from hv_balloon Linux kernel driver, adapted to the QEMU coding style and
definitions.
Acked-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
include/hw/hyperv/dynmem-pro
From: "Maciej S. Szmigiero"
Add the necessary plumbing for the hv-balloon driver to the PC machine.
Co-developed-by: David Hildenbrand
Reviewed-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/i386/Kconfig | 1 +
hw/i386/pc.c| 22 ++
2 fil
From: "Maciej S. Szmigiero"
Acked-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e8a7d5be5de..d4a480ce5a62 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2656,6 +26
From: "Maciej S. Szmigiero"
Used by the driver to report its provided memory state information.
Co-developed-by: David Hildenbrand
Reviewed-by: David Hildenbrand
Acked-by: Markus Armbruster
Signed-off-by: Maciej S. Szmigiero
---
hw/core/machine-hmp-cmds.c | 15 +++
hw
From: "Maciej S. Szmigiero"
Used by the hv-balloon driver for (optional) guest memory status reports.
Acked-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/hyperv/hv-balloon.c | 30 +++-
monitor/monitor.c | 1 +
qapi/machine.json
From: David Hildenbrand
Let's support empty memory devices -- memory devices that don't have a
memory device region in the current configuration. hv-balloon with an
optional memdev is the primary use case.
Signed-off-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/mem/memory
From: David Hildenbrand
There is no strong requirement that the size has to be multiples of the
requested alignment, let's drop it. This is a preparation for hv-baloon.
Signed-off-by: David Hildenbrand
Signed-off-by: Maciej S. Szmigiero
---
hw/mem/memory-device.c | 6 --
1 file changed
From: "Maciej S. Szmigiero"
One of advantages of using this protocol over ACPI-based PC DIMM hotplug is
that it allows hot-adding memory in much smaller granularity because the
ACPI DIMM slot limit does not apply.
In order to enable this functionality a new memory backend needs to
From: "Maciej S. Szmigiero"
The following changes since commit d762bf97931b58839316b68a570eecc6143c9e3e:
Merge tag 'pull-target-arm-20231102' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging (2023-11-03
10:04:12 +0800)
are available in the Git repository at
From: "Maciej S. Szmigiero"
This driver is like virtio-balloon on steroids: it allows both changing the
guest memory allocation via ballooning and (in the next patch) inserting
pieces of extra RAM into it on demand from a provided memory backend.
The actual resizing is done via
On 2.11.2023 14:50, David Hildenbrand wrote:
On 23.10.23 19:24, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This is a continuation of the v7 of the patch series located here:
https://lore.kernel.org/qemu-devel/cover.1693240836.git.maciej.szmigi...@oracle.com/
I skimmed
On 26.10.2023 11:31, Анастасия Любимова wrote:
28/09/23 19:18, Maciej S. Szmigiero пишет:
On 28.09.2023 15:25, Anastasia Belova wrote:
cpu_physical_memory_map may return NULL in hyperv_hcall_post_message.
Add check for NULL to avoid NULL-dereference.
Found by Linux Verification Center
1 - 100 of 232 matches
Mail list logo
