On Apr 10, 2023, at 11:39 AM, Andrey Ryabinin wrote:
>>>
>>>
>>>
>>> On 4/10/23 10:35, Andrey Ryabinin wrote:
>>>> Some guests hang on boot when using the vhost-user-blk-pci device,
>>>> but boot normally when using the virtio-blk device.
ile vhost-user-blk is not.
We've been using virtio-blk in our cloud for a while and recently started
switching to vhost-user-blk
which led us to discover this problem.
>> On Apr 10, 2023, at 11:39 AM, Andrey Ryabinin wrote:
>>
>>
>>
>> On 4/10/23 10:35, Andrey
On 4/10/23 10:35, Andrey Ryabinin wrote:
> Some guests hang on boot when using the vhost-user-blk-pci device,
> but boot normally when using the virtio-blk device. The problem occurs
> because the guest advertises VIRTIO_F_VERSION_1 but kicks the virtqueue
> be
s the similar
thing in its virtio_blk_handle_output() function.
Fixes: 110b9463d5c8 ("vhost-user-blk: start vhost when guest kicks")
Signed-off-by: Andrey Ryabinin
---
hw/block/vhost-user-blk.c | 4
1 file changed, 4 deletions(-)
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
i
On 10/17/22 18:21, Alex Williamson wrote:
> On Mon, 17 Oct 2022 13:54:03 +0300
> Andrey Ryabinin wrote:
>
>> These patches add possibility to pass VFIO device to QEMU using file
>> descriptors of VFIO container/group, instead of creating those by QEMU.
>> This allo
On 10/17/22 14:05, Daniel P. Berrangé wrote:
> On Mon, Oct 17, 2022 at 01:54:03PM +0300, Andrey Ryabinin wrote:
>> These patches add possibility to pass VFIO device to QEMU using file
>> descriptors of VFIO container/group, instead of creating those by QEMU.
>> This allows to
r representing IOMMU group (no needed if @fd
and @container were provided)
E.g.:
-object vfio-container,id=ct,fd=5 \
-object vfio-group,id=group,fd=6,container=ct
Signed-off-by: Andrey Ryabinin
---
hw/vfio/common.
Add vfio-container type and allow user to create vfio-container
object via '-object' command line argument or 'object-add' qmp command.
Add 'fd' parameter to this type to allow user provide file descriptor of
a vfio-container.
E.g.
-object vfio-container,id=
_FLAG_VADDR/VFIO_DMA_MAP_FLAG_VADDR
And doesn't require new migration mode, just some additional steps from
management layer.
Andrey Ryabinin (4):
vfio: add vfio-container user createable object
vfio: add vfio-group user createable object
vfio: Add 'group' property to 'vfio
to it.
Signed-off-by: Andrey Ryabinin
---
tests/avocado/vfio.py | 156 ++
1 file changed, 156 insertions(+)
create mode 100644 tests/avocado/vfio.py
diff --git a/tests/avocado/vfio.py b/tests/avocado/vfio.py
new file mode 100644
index 000..fa0d2b
Add 'group' properties to 'vfio-pci' device. This allows
to add vfio-pci device using precreated vfio container and group, e.g.
-object vfio-container,id=ct,fd=5 \
-object vfio-group,id=grp,fd=6,container=ct \
-device vfio-pci,host=05:00.0,group=grp
S
pxb/pxb-pcie/pxb-cxl devices currently doesn't have vmstate description
So the state of device is not preserved during migration and
guest can notice that as change of PCI_COMMAND_* registers state.
The diff of lspci output before and after migration:
00:03.0 Host bridge [0600]: Red Hat, Inc. QE
On 6/15/22 16:12, Stefan Hajnoczi wrote:
> On Tue, Jun 14, 2022 at 02:18:42PM +0300, Andrey Ryabinin wrote:
>> This reverts commit 9b938c7262e4 ("chardev: clear O_NONBLOCK on SCM_RIGHTS
>> file descriptors").
>> File descriptor passed to QEMU via 'get
On 6/15/22 16:10, Stefan Hajnoczi wrote:
> On Tue, Jun 14, 2022 at 02:18:41PM +0300, Andrey Ryabinin wrote:
>> Hi
>>
>> These couple patches aims to make possible local migration (within one host)
>> on the same TAP device used by source and destination QEMU
>>
MU
2. Launch destination QEMU (-incoming defer) and pass same descriptors to it.
3. Start migration
In such scenario setting blocking state at stage (2) will hang source QEMU
since TAP fd suddenly become blocking.
Signed-off-by: Andrey Ryabinin
---
chardev/char-socket.c | 3 ---
io/channel-sock
e, besides
fd_start_incoming_migration()
I need to put qemu_socket_set_block() calls.
Andrey Ryabinin (2):
chardev: don't set O_NONBLOCK on SCM_RIGHTS file descriptors.
tap: initialize TAPState->enabled according to the actual state of
queue
chardev/char-socket.c | 3 ---
io/channel-socket.c |
ble(s->fd);
...
return ret;
assert(!r);
Initialize ->enabled according to the actual state of fd to fix this.
Signed-off-by: Andrey Ryabinin
---
net/tap-bsd.c | 5 +
net/tap-linux.c | 12
net/tap-solaris.c | 5 +
net/tap.c
On 3/30/22 22:25, Peter Xu wrote:
> On Fri, Mar 25, 2022 at 06:40:13PM +0300, Andrey Ryabinin wrote:
>> The sequence of ram_block_add()/qemu_ram_free()/ram_block_add()
>> function calls leads to leaking some memory.
>>
>> ram_block_add() calls dirty_memory_extend(
lready allocated on CPU#1
dirty memory bitmap blocks.
Fix this by moving last_ram_page() call under the qemu_mutex_lock_ramlist()
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andrey Ryabinin
---
softmmu/physmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/softmmu/p
st.dirty_memory[] for safe RAM hotplug")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andrey Ryabinin
---
include/exec/ramlist.h | 2 ++
softmmu/physmem.c | 38 --
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/include/exec/ramlist.h b/in
20 matches
Mail list logo
