On 13/04/2023 14:03, Stefan Hajnoczi wrote:
On Thu, 13 Apr 2023 at 04:20, Hanna Czenczek wrote:
On 12.04.23 22:51, Stefan Hajnoczi wrote:
On Tue, Apr 11, 2023 at 05:05:12PM +0200, Hanna Czenczek wrote:
If the back-end supports the VHOST_USER_F_PROTOCOL_FEATURES feature,
setting the vhost
On 21/03/2023 19:49, Hanna Czenczek wrote:
On 20.03.23 13:39, Anton Kuchin wrote:
On 20/03/2023 11:33, Hanna Czenczek wrote:
On 17.03.23 19:37, Anton Kuchin wrote:
On 17/03/2023 19:52, Hanna Czenczek wrote:
On 17.03.23 18:19, Anton Kuchin wrote:
On 13/03/2023 19:48, Hanna Czenczek wrote
On 20/03/2023 11:33, Hanna Czenczek wrote:
On 17.03.23 19:37, Anton Kuchin wrote:
On 17/03/2023 19:52, Hanna Czenczek wrote:
On 17.03.23 18:19, Anton Kuchin wrote:
On 13/03/2023 19:48, Hanna Czenczek wrote:
A virtio-fs device's VM state consists of:
- the virtio device (vring) state
On 01/03/2023 17:33, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
We can't rely here entirely on
destination to block this because if VM is migrated to file and then
can't be loaded by destination there is no way to fallback and resume
the source so we
On 17/03/2023 19:52, Hanna Czenczek wrote:
On 17.03.23 18:19, Anton Kuchin wrote:
On 13/03/2023 19:48, Hanna Czenczek wrote:
A virtio-fs device's VM state consists of:
- the virtio device (vring) state (VMSTATE_VIRTIO_DEVICE)
- the back-end's (virtiofsd's) internal state
We get/set the latter
On 06/03/2023 23:53, Michael S. Tsirkin wrote:
On Mon, Mar 06, 2023 at 10:55:29PM +0200, Anton Kuchin wrote:
On 01/03/2023 22:22, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 09:35:56PM +0200, Anton Kuchin wrote:
I do trust them :)
I have to, otherwise we would need to pack all
On 13/03/2023 19:48, Hanna Czenczek wrote:
Add a virtio-fs-specific vhost-user interface to facilitate migrating
back-end-internal state. We plan to migrate the internal state simply
as a binary blob after the streaming phase, so all we need is a way to
transfer such a blob from and to the
On 13/03/2023 19:48, Hanna Czenczek wrote:
A virtio-fs device's VM state consists of:
- the virtio device (vring) state (VMSTATE_VIRTIO_DEVICE)
- the back-end's (virtiofsd's) internal state
We get/set the latter via the new vhost-user operations FS_SET_STATE_FD,
FS_GET_STATE, and FS_SET_STATE.
On 01/03/2023 22:22, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 09:35:56PM +0200, Anton Kuchin wrote:
I do trust them :)
I have to, otherwise we would need to pack all the properties and
flags of qemu to the migration stream and validate them at
destination or entire migration ends up
On 01/03/2023 17:52, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:40:09PM +0200, Anton Kuchin wrote:
So catching errors in not the only purpose of this property, but it
definitely
allows us to catch some obvious ones.
OK let's say this. If migration=external then migration just works
On 01/03/2023 19:17, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 06:04:31PM +0200, Anton Kuchin wrote:
On 01/03/2023 17:24, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:07:28PM +0200, Anton Kuchin wrote:
On 28/02/2023 23:24, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 07
On 01/03/2023 17:52, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:40:09PM +0200, Anton Kuchin wrote:
So catching errors in not the only purpose of this property, but it
definitely
allows us to catch some obvious ones.
OK let's say this. If migration=external then migration just works
On 01/03/2023 17:24, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:07:28PM +0200, Anton Kuchin wrote:
On 28/02/2023 23:24, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
On 28/02/2023 16:57, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 04
On 01/03/2023 16:46, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2023 at 05:03:03PM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 01.03.23 00:24, Michael S. Tsirkin wrote:
Said that checking on destination would need another flag and the safe
way of using this feature would require managing
On 28/02/2023 23:24, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
On 28/02/2023 16:57, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
I really don't understand why and what do you want to check on
destination
On 28/02/2023 16:57, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
I really don't understand why and what do you want to check on
destination.
Yes I understand your patch controls source. Let me try to rephrase
why I think it's better on destination
, Anton Kuchin wrote:
On 22/02/2023 19:12, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:
On 22/02/2023 18:51, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:
On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote
On 24/02/2023 06:14, Anton Kuchin wrote:
On 23/02/2023 23:24, Stefan Hajnoczi wrote:
On Thu, Feb 23, 2023 at 02:36:33AM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
On 22
On 23/02/2023 23:24, Stefan Hajnoczi wrote:
On Thu, Feb 23, 2023 at 02:36:33AM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
On 22/02/2023 19:12, Michael S. Tsirkin wrote
On 22/02/2023 22:21, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:
On 22/02/2023 19:12, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:
On 22/02/2023 18:51, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 06
On 22/02/2023 19:12, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:
On 22/02/2023 18:51, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:
On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
On 22.02.23 17:25
On 22/02/2023 18:43, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 06:14:31PM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 22.02.23 17:25, Anton Kuchin wrote:
+static int vhost_user_fs_pre_save(void *opaque)
+{
+ VHostUserFS *fs = opaque;
+ g_autofree char *path
On 22/02/2023 18:51, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:
On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
On 22.02.23 17:25, Anton Kuchin wrote:
+static int vhost_user_fs_pre_save(void *opaque)
+{
+ VHostUserFS *fs = opaque
On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
On 22.02.23 17:25, Anton Kuchin wrote:
+static int vhost_user_fs_pre_save(void *opaque)
+{
+ VHostUserFS *fs = opaque;
+ g_autofree char *path = object_get_canonical_path(OBJECT(fs));
+
+ switch (fs->migration_type) {
+ c
On 22/02/2023 14:43, Michael S. Tsirkin wrote:
On Wed, Feb 22, 2023 at 03:20:00PM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 17.02.23 20:00, Anton Kuchin wrote:
Migration of vhost-user-fs device requires transfer of FUSE internal state
from backend. There is no standard way to do it now so
On 22/02/2023 14:20, Vladimir Sementsov-Ogievskiy wrote:
On 17.02.23 20:00, Anton Kuchin wrote:
Migration of vhost-user-fs device requires transfer of FUSE internal
state
from backend. There is no standard way to do it now so by default
migration
must be blocked. But if this state can
-by: Anton Kuchin
---
hw/core/qdev-properties-system.c| 10 +
hw/virtio/vhost-user-fs.c | 32 -
include/hw/qdev-properties-system.h | 1 +
include/hw/virtio/vhost-user-fs.h | 2 ++
qapi/migration.json | 16 +++
5 files
v3:
- Remove migration_type from migration stream
- Use enum type for migration_type
- Get rid of useless cast
- Fix typos
- Reword commit message
v2:
- Use device property instead of migration capability
Anton Kuchin (1):
vhost-user-fs: add migration type property
hw/core/qdev
/* resend with fixed to: and cc: */
On 16/02/2023 18:22, Juan Quintela wrote:
"Michael S. Tsirkin" wrote:
On Thu, Feb 16, 2023 at 11:11:22AM -0500, Michael S. Tsirkin wrote:
On Thu, Feb 16, 2023 at 03:14:05PM +0100, Juan Quintela wrote:
Anton Kuchin wrote:
Now any vhost-user
On 16/02/2023 18:22, Juan Quintela wrote:
"Michael S. Tsirkin" wrote:
On Thu, Feb 16, 2023 at 11:11:22AM -0500, Michael S. Tsirkin wrote:
On Thu, Feb 16, 2023 at 03:14:05PM +0100, Juan Quintela wrote:
Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable,
On 16/02/2023 23:09, Stefan Hajnoczi wrote:
On Thu, Feb 16, 2023 at 04:00:03PM +0200, Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable, that also prevents
qemu update without stopping the VM. In most cases that makes sense
because qemu has no way to transfer FUSE session
v2: Use device property instead of migration capability
Anton Kuchin (1):
vhost-user-fs: add property to allow migration
hw/core/qdev-properties-system.c| 10 +
hw/virtio/vhost-user-fs.c | 34 -
include/hw/qdev-properties-system.h | 1
from qemu.
Signed-off-by: Anton Kuchin
---
hw/core/qdev-properties-system.c| 10 +
hw/virtio/vhost-user-fs.c | 34 -
include/hw/qdev-properties-system.h | 1 +
include/hw/virtio/vhost-user-fs.h | 1 +
qapi/migration.json | 16
On 13/02/2023 16:01, Vladimir Sementsov-Ogievskiy wrote:
To be used in further patch to identify the device hot-plugged into
pcie-root-port.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Anton Kuchin
---
include/hw/pci/pci.h | 1 +
hw/pci/pci.c | 33
On 13/02/2023 16:00, Vladimir Sementsov-Ogievskiy wrote:
It should be zero, the only valid values are ON, OFF and BLINK.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Anton Kuchin
---
hw/pci/pcie.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/pci/pcie.c b/hw/pci
etter code is in pcie_cap_slot_unplug_request_cb() and in
pcie_cap_update_power(). Let's use same pattern everywhere. To simplify
things add also a helper.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Anton Kuchin
---
hw/pci/pcie.c | 16 ++--
1 file c
-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Anton Kuchin
---
hw/pci/pcie.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index ccdb2377e1..db8360226f 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -373,8 +373,8 @@ void
On 13/02/2023 16:00, Vladimir Sementsov-Ogievskiy wrote:
The structure type is unused. Also, it's the only user of corresponding
macros, so drop them too.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Anton Kuchin
---
include/hw/pci/pcie.h
/pcie.c, so let's be consistent)
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Anton Kuchin
---
include/hw/pci/pcie_regs.h | 9 -
hw/pci/pcie.c | 13 +++--
2 files changed, 7 insertions(+), 15 deletions(-)
diff
EXP_SLTCTL_PIC_OFF)) {
pcie_cap_slot_do_unplug(dev);
}
pcie_cap_update_power(dev);
Reviewed-by: Anton Kuchin
error_propagate(errp, local_err);
+if (!shpc_device_get_slot(PCI_DEVICE(dev), , shpc, errp)) {
return;
}
Reviewed-by: Anton Kuchin
nt64_t val, int l)
shpc->config[a] &= ~(val & w1cmask); /* W1C: Write 1 to Clear */
}
if (ranges_overlap(addr, l, SHPC_CMD_CODE, 2)) {
-shpc_command(shpc);
+shpc_command(d);
}
shpc_interrupt_update(d);
}
Reviewed-by: Anton Kuchin
(shpc, slot);
+shpc_set_status(shpc, slot, 1, SHPC_SLOT_STATUS_MRL_OPEN);
+shpc_set_status(shpc, slot, SHPC_SLOT_STATUS_PRSNT_EMPTY,
+SHPC_SLOT_STATUS_PRSNT_MASK);
+shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |=
+SHPC_SLOT_EVENT_MRL |
+SHPC_SLOT_EVENT_PRESENCE;
}
}
Reviewed-by: Anton Kuchin
power = shpc_get_status(shpc, slot, SHPC_SLOT_PWR_LED_MASK);
/* TODO: track what monitor requested. */
/* Look at LED to figure out whether it's ok to remove the device. */
Reviewed-by: Anton Kuchin
gt;> ctz32(msk);
+uint16_t result = (pci_get_word(status) & msk) >> ctz32(msk);
+
+assert(result <= UINT8_MAX);
+return result;
}
static void shpc_set_status(SHPCDevice *shpc,
Reviewed-by: Anton Kuchin
, SHPC_SLOT_ATTN_LED_MASK);
shpc_set_status(shpc, i, 0, SHPC_SLOT_STATUS_66);
}
shpc_set_sec_bus_speed(shpc, SHPC_SEC_BUS_33);
Reviewed-by: Anton Kuchin
On 02/02/2023 11:59, Juan Quintela wrote:
Anton Kuchin wrote:
On 01/02/2023 16:26, Juan Quintela wrote:
Anton Kuchin wrote:
On 19/01/2023 18:02, Stefan Hajnoczi wrote:
On Thu, 19 Jan 2023 at 10:29, Anton Kuchin wrote:
On 19/01/2023 16:30, Stefan Hajnoczi wrote:
On Thu, 19 Jan 2023 at 07
On 01/02/2023 16:26, Juan Quintela wrote:
Anton Kuchin wrote:
On 19/01/2023 18:02, Stefan Hajnoczi wrote:
On Thu, 19 Jan 2023 at 10:29, Anton Kuchin wrote:
On 19/01/2023 16:30, Stefan Hajnoczi wrote:
On Thu, 19 Jan 2023 at 07:43, Anton Kuchin wrote:
On 18/01/2023 17:52, Stefan Hajnoczi
On 26/01/2023 17:13, Stefan Hajnoczi wrote:
On Thu, 26 Jan 2023 at 09:20, Anton Kuchin wrote:
On 25/01/2023 21:46, Stefan Hajnoczi wrote:
On Sun, Jan 15, 2023 at 07:09:03PM +0200, Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable, that also prevents
qemu update without
On 25/01/2023 21:46, Stefan Hajnoczi wrote:
On Sun, Jan 15, 2023 at 07:09:03PM +0200, Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable, that also prevents
qemu update without stopping the VM. In most cases that makes sense
because qemu has no way to transfer FUSE session
On 23/01/2023 16:09, Stefan Hajnoczi wrote:
On Sun, 22 Jan 2023 at 11:18, Michael S. Tsirkin wrote:
On Sun, Jan 22, 2023 at 06:09:40PM +0200, Anton Kuchin wrote:
On 22/01/2023 16:46, Michael S. Tsirkin wrote:
On Sun, Jan 22, 2023 at 02:36:04PM +0200, Anton Kuchin wrote:
This flag should
On 22/01/2023 16:46, Michael S. Tsirkin wrote:
On Sun, Jan 22, 2023 at 02:36:04PM +0200, Anton Kuchin wrote:
This flag should be set when qemu don't need to worry about any
external state stored in vhost-user daemons during migration:
don't fail migration, just pack generic virtio device
On 22/01/2023 10:16, Michael S. Tsirkin wrote:
On Fri, Jan 20, 2023 at 07:37:18PM +0200, Anton Kuchin wrote:
On 20/01/2023 15:58, Michael S. Tsirkin wrote:
On Thu, Jan 19, 2023 at 03:45:06PM +0200, Anton Kuchin wrote:
On 19/01/2023 14:51, Michael S. Tsirkin wrote:
On Sun, Jan 15, 2023 at 07
On 20/01/2023 15:58, Michael S. Tsirkin wrote:
On Thu, Jan 19, 2023 at 03:45:06PM +0200, Anton Kuchin wrote:
On 19/01/2023 14:51, Michael S. Tsirkin wrote:
On Sun, Jan 15, 2023 at 07:09:03PM +0200, Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable, that also prevents
qemu
On 19/01/2023 21:00, Dr. David Alan Gilbert wrote:
* Anton Kuchin (antonkuc...@yandex-team.ru) wrote:
On 19/01/2023 14:51, Michael S. Tsirkin wrote:
On Sun, Jan 15, 2023 at 07:09:03PM +0200, Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable, that also prevents
qemu
On 19/01/2023 18:02, Stefan Hajnoczi wrote:
On Thu, 19 Jan 2023 at 10:29, Anton Kuchin wrote:
On 19/01/2023 16:30, Stefan Hajnoczi wrote:
On Thu, 19 Jan 2023 at 07:43, Anton Kuchin wrote:
On 18/01/2023 17:52, Stefan Hajnoczi wrote:
On Sun, 15 Jan 2023 at 12:21, Anton Kuchin wrote:
Now
On 19/01/2023 16:30, Stefan Hajnoczi wrote:
On Thu, 19 Jan 2023 at 07:43, Anton Kuchin wrote:
On 18/01/2023 17:52, Stefan Hajnoczi wrote:
On Sun, 15 Jan 2023 at 12:21, Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable, that also prevents
qemu update without stopping
On 19/01/2023 14:51, Michael S. Tsirkin wrote:
On Sun, Jan 15, 2023 at 07:09:03PM +0200, Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable, that also prevents
qemu update without stopping the VM. In most cases that makes sense
because qemu has no way to transfer FUSE
On 18/01/2023 17:52, Stefan Hajnoczi wrote:
On Sun, 15 Jan 2023 at 12:21, Anton Kuchin wrote:
Now any vhost-user-fs device makes VM unmigratable, that also prevents
qemu update without stopping the VM. In most cases that makes sense
because qemu has no way to transfer FUSE session state
will be preserved (e.g. it uses migration to
update qemu and dst will run on the same host as src and use the same
socket endpoints).
This patch keeps default behavior that prevents migration with such devices
but adds migration capability 'vhost-user-fs' to explicitly allow migration.
Signed-off-by: Anton
On 09/04/2021 18:56, Vivek Goyal wrote:
On Thu, Apr 08, 2021 at 10:55:34PM +0300, Anton Kuchin wrote:
Make virtio-fs take into account server capabilities.
Just returning requested features assumes they all of then are implemented
by server and results in setting unsupported configuration
Make virtio-fs take into account server capabilities.
Just returning requested features assumes they all of then are implemented
by server and results in setting unsupported configuration if some of them
are absent.
Signed-off-by: Anton Kuchin
---
hw/virtio/vhost-user-fs.c | 17
Hi,
I'm implementing migration support in vhost-user backend and have a
couple of questions:
1. How master can be sure that logging was started?
We expect that right after set_fatures command with VHOST_F_LOG_ALL flag
all memory modifications will be tracked in log, but slave can need a
little
On transition to running first apply state to bus and then to device
so device can access bus functions correctly. When going to stopped
notify device first and then the bus.
Signed-off-by: Anton Kuchin
---
hw/virtio/virtio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Signed-off-by: Anton Kuchin
---
hw/net/virtio-net.c| 3 +--
include/hw/virtio/virtio-net.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index b9e1cd71cf..16d2ad5927 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio
Hi,
I'm trying to understand contexts and handlers/notifiers and a bit
confused about two contexts living in main loop: qemu_aio_context and
iohandler_ctx. It is mentioned in the iohandler_ctx comment that
qemu_aio_context can't be reused because "iohandlers mustn't be polled
by
Close involves flush that can be performed asynchronously and bs
must be protected from being referenced before it is deleted.
Signed-off-by: Anton Kuchin
---
block.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index 9ae5c0ed2f..b505271a4d 100644
On 29/04/2019 13:38, Kevin Wolf wrote:
Am 26.04.2019 um 14:24 hat Anton Kuchin geschrieben:
I can't figure out ownership of aio context during bdrv_close().
As far as I understand bdrv_unref() shold be called with acquired aio
context to prevent concurrent operations (at least most usages
I can't figure out ownership of aio context during bdrv_close().
As far as I understand bdrv_unref() shold be called with acquired aio
context to prevent concurrent operations (at least most usages in
blockdev.c explicitly acquire and release context, but not all).
But if refcount reaches
As far as I can see currently IOThread offloading is used only for block
devices and all others are emulated by main thread.
I expect that network devices can also benefit from processing in
separate thread but I couldn't find any recent work in this direction.
I'm going to implement a PoC
Only part of block/qapi.c is used by qemu-io qemu-nbd and qemu-img
and its not realy about QAPI, so move it to separate file to reduce
amount of unused code linked to utilities and avoid unnecessary
dependencies.
Signed-off-by: Anton Kuchin
---
block.c | 2
On 28/01/2019 18:37, Kevin Wolf wrote:
Am 28.01.2019 um 16:15 hat Anton Kuchin geschrieben:
This option is broken since a6baa60807 in v2.9 and returns mostly
zeroes instead of real stats because actual querring of BlockStats
that resides in blk is missing.
And it makes no sense because
On 28/01/2019 17:47, Kevin Wolf wrote:
Am 28.01.2019 um 15:27 hat Anton Kuchin geschrieben:
Some HMP and QMP commands are targeting BlockBackend but
for hotplugged devices name of BB is deprecated, instead
name of root BlockDriverState is set. These patches add
functions to search BB
since 7f0e9da6f13 in v2.5
Signed-off-by: Anton Kuchin
---
block/qapi.c | 26 +++---
qapi/block-core.json | 8 +---
qemu-deprecated.texi | 5 +
3 files changed, 13 insertions(+), 26 deletions(-)
diff --git a/block/qapi.c b/block/qapi.c
index c66f949db8
-by: Anton Kuchin
---
block/block-backend.c | 29 +
include/sysemu/block-backend.h | 7 +++
2 files changed, 36 insertions(+)
diff --git a/block/block-backend.c b/block/block-backend.c
index 60d37a0c3d..86a492853c 100644
--- a/block/block-backend.c
+++ b
it's more convinient than accessing BB
by QOM path.
Anton Kuchin (2):
block: add functions to search BlockBackend by root BDS name
block: migrate callers from blk_by_name to blk_lookup
block/block-backend.c | 29 +
blockdev-nbd.c | 2
Signed-off-by: Anton Kuchin
---
blockdev-nbd.c | 2 +-
blockdev.c | 6 +++---
hmp.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index d73ac1b026..f2ea7318cf 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -162,7 +162,7
. This will work a little slower but I see no hot paths that
will be affected. And this way transition will be transparent to users
but I'm not sure this can be done in backward compatible way.
Do you have any suggestions how to do it correctly?
On 11/12/2018 12:47, Kevin Wolf wrote:
[...]
Anton Kuchin
Hello,
I'm trying to switch from -drive parameter to -blockdev + -device and
having problems. Looks like with this option I have no way to set the
name of created BlockBackend, but some QMP and HMP commands are trying
to find blk with blk_by_name() and fail to locate my device (e.g.
79 matches
Mail list logo
