Apparently, looks like it is a firmware bug.
Both seaBIOS/OVMF set IA32_FEATURE_CONTROL only during init from
qemu-provided etc/msr_feature_control.
So probably the fix should be done in the firmware then.
On 6/9/25 20:25, Sean Christopherson wrote:
On Mon, Jun 09, 2025, Andrey Zhadchenko
On 6/9/25 18:39, Sean Christopherson wrote:
On Mon, Jun 09, 2025, Denis V. Lunev wrote:
On 6/9/25 18:12, Paolo Bonzini wrote:
On 6/9/25 15:23, Andrey Zhadchenko wrote:
When hotplugging vCPUs to the Windows vms, we observed strange instance
crash on Intel(R) Xeon(R) CPU E3-1230 v6:
panic
a hack.
This patch introduces new CPU option: QEMU will copy msr 3a value from
the first vCPU during the hotplug. This problem may not be limited to
SGX feature, so the whole register is copied.
By default the option is set to auto and hyper-v is used as Windows
indicator to enable this new featu
API to manipulate meta bitmap was removed with commit 0c88f1970c76
Signed-off-by: Andrey Zhadchenko
Reviewed-by: Eric Blake
---
util/hbitmap.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/util/hbitmap.c b/util/hbitmap.c
index d9a1dabc63..16674f33e4
until the non-accessible area
Signed-off-by: Andrey Zhadchenko
---
block/copy-before-write.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/block/copy-before-write.c b/block/copy-before-write.c
index 7e074ad569..c5e6e1c112 100644
--- a/block/copy-before
cbw + snap 325s 413s
cbw + snap + patch 55s 61s
To fix it, inverse the access bitmap in cbw filter: rather set it
when the user is not allowed to read the cluster.
Update qemu-iotest 257: now access bitmap have count 0 instead of
the image size 67108864
Signed-off-by: Andrey Zhadchenko
---
and bdrv_dirty_bitmap_inverse() helper
Signed-off-by: Andrey Zhadchenko
---
block/dirty-bitmap.c | 9 +
include/block/block_int-io.h | 1 +
include/qemu/hbitmap.h | 8
util/hbitmap.c | 15 +++
4 files changed, 33 insertions(+)
diff
is empty,
so count is 0 instead of 67108864 (which is the image size)
- remove meta betmap leftovers
- report block_status() until the end of accessible section to
snapshot filter, instead of returning EINVAL on big requests
v2:
- use 'inverse' instead of reverse, add an example
Andrey Zha
On 5/20/25 18:29, Eric Blake wrote:
[?? ??? ? ?? ?? ebl...@redhat.com. ???, ?? ??? ?,
?? ?? https://aka.ms/LearnAboutSenderIdentification ]
On Tue, May 13, 2025 at 03:32:36AM +0200, Andrey Zhadchenko wrote:
and bdrv_dirty_bitmap_reverse() helper
Is
On 5/20/25 19:26, Eric Blake wrote:
[?? ??? ? ?? ?? ebl...@redhat.com. ???, ?? ??? ?,
?? ?? https://aka.ms/LearnAboutSenderIdentification ]
On Tue, May 13, 2025 at 03:32:37AM +0200, Andrey Zhadchenko wrote:
HBitmaps allow us to search set bits pretty fast
and bdrv_dirty_bitmap_reverse() helper
Signed-off-by: Andrey Zhadchenko
---
block/dirty-bitmap.c | 9 +
include/block/block_int-io.h | 1 +
include/qemu/hbitmap.h | 8
util/hbitmap.c | 15 +++
4 files changed, 33 insertions(+)
diff
API to manipulate meta bitmap was removed with commit 0c88f1970c76
Signed-off-by: Andrey Zhadchenko
---
util/hbitmap.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/util/hbitmap.c b/util/hbitmap.c
index d9a1dabc63..16674f33e4 100644
--- a/util/hbitmap.c
until the non-accessible area
Signed-off-by: Andrey Zhadchenko
---
block/copy-before-write.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/block/copy-before-write.c b/block/copy-before-write.c
index 5f5b3e7515..81d7f40b13 100644
--- a/block/copy-before
is empty,
so count is 0 instead of 67108864 (which is the image size)
- remove meta betmap leftovers
- report block_status() until the end of accessible section to
snapshot filter, instead of returning EINVAL on big requests
Andrey Zhadchenko (4):
hbitmap: drop meta bitmap leftovers
hbitmap: in
cbw + snap 325s 413s
cbw + snap + patch 55s 61s
To fix it, reverse the access bitmap in cbw filter: rather set it
when the user is not allowed to read the cluster.
Update qemu-iotest 257: now access bitmap have count 0 instead of
the image size 67108864
Signed-off-by: Andrey Zhadchenko
---
Hi!
Thanks for the review
On 9/12/23 21:29, Vladimir Sementsov-Ogievskiy wrote:
On 04.09.23 11:31, Andrey Zhadchenko wrote:
Unlike other transaction commands, bitmap operations do not drain target
bds. If we have an IOThread, this may result in some inconsistencies, as
bitmap content may
fo() to return NULL for filters in a such
state. Modify bdrv_named_nodes_list() to skip bds for which it cannot
get an info.
Signed-off-by: Andrey Zhadchenko
---
block.c | 7 +--
block/qapi.c | 5 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index
s patchset also adds simple test for this case.
Andrey Zhadchenko (2):
block: do not try to list nearly-dropped filters
iotests: add new test case for image streaming
block.c| 7 +--
block/qapi.c | 5 +
tests/qemu-iotests/030 | 17 ++
Check if we can list named block nodes when the block-stream is
finalized but not yet dismissed
This previously led to a crash
Signed-off-by: Andrey Zhadchenko
---
tests/qemu-iotests/030 | 17 +
tests/qemu-iotests/030.out | 4 ++--
2 files changed, 19 insertions(+), 2
Unlike other transaction commands, bitmap operations do not drain target
bds. If we have an IOThread, this may result in some inconsistencies, as
bitmap content may change during transaction command.
Add bdrv_drained_begin()/end() to bitmap operations.
Signed-off-by: Andrey Zhadchenko
Now all transaction actions drain their respective bds
Also, bdrv_drain_all() did not protect anything in case of IOThreads
Signed-off-by: Andrey Zhadchenko
---
blockdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 7a376fce90..65932f9afb 100644
--- a
On 2/3/23 13:55, Andrey Zhadchenko wrote:
On 2/2/23 22:39, Eric Blake wrote:
On Thu, Feb 02, 2023 at 09:15:23PM +0300, Andrey Zhadchenko via wrote:
The last return statement should return true, as we already evaluated
that
start == next_dirty
Also, fix hbitmap_status() description in
On 2/2/23 22:39, Eric Blake wrote:
On Thu, Feb 02, 2023 at 09:15:23PM +0300, Andrey Zhadchenko via wrote:
The last return statement should return true, as we already evaluated that
start == next_dirty
Also, fix hbitmap_status() description in header
Cc: qemu-sta...@nongnu.org
Fixes
The last return statement should return true, as we already evaluated that
start == next_dirty
Also, fix hbitmap_status() description in header
Cc: qemu-sta...@nongnu.org
Fixes: a6426475a75 ("block/dirty-bitmap: introduce bdrv_dirty_bitmap_status()")
Signed-off-by: Andrey
| 803k | 779k | *two kernel threads
v2:
- fix g_new() to g_new0() for vq allocations
- add multithreading support
- fix last agrument in vhost_dev_init()
- kick all vqueues in start, not only the first one
Signed-off-by: Andrey Zhadchenko
---
hw/block/Kconfig
| 779k | *two kernel threads
Andrey Zhadchenko (1):
block: add vhost-blk backend
hw/block/Kconfig | 5 +
hw/block/meson.build | 4 +
hw/block/vhost-blk.c | 403 ++
hw/virtio/meson.build | 3 +
hw/virtio/vhost-blk
Thanks for the review!
On 10/4/22 21:45, Stefan Hajnoczi wrote:
On Mon, Jul 25, 2022 at 11:55:27PM +0300, Andrey Zhadchenko wrote:
Although QEMU virtio is quite fast, there is still some room for
improvements. Disk latency can be reduced if we handle virito-blk requests
in host kernel istead
On 10/4/22 22:00, Stefan Hajnoczi wrote:
On Mon, Jul 25, 2022 at 11:55:26PM +0300, Andrey Zhadchenko wrote:
Although QEMU virtio-blk is quite fast, there is still some room for
improvements. Disk latency can be reduced if we handle virito-blk requests
in host kernel so we avoid a lot of
On 10/4/22 21:26, Stefan Hajnoczi wrote:
On Mon, Jul 25, 2022 at 11:55:26PM +0300, Andrey Zhadchenko wrote:
Although QEMU virtio-blk is quite fast, there is still some room for
improvements. Disk latency can be reduced if we handle virito-blk requests
in host kernel so we avoid a lot of
On 10/4/22 21:13, Stefan Hajnoczi wrote:
On Mon, Jul 25, 2022 at 11:55:26PM +0300, Andrey Zhadchenko wrote:
Although QEMU virtio-blk is quite fast, there is still some room for
improvements. Disk latency can be reduced if we handle virito-blk requests
in host kernel so we avoid a lot of
On 7/27/22 16:06, Stefano Garzarella wrote:
On Tue, Jul 26, 2022 at 04:15:48PM +0200, Denis V. Lunev wrote:
On 26.07.2022 15:51, Michael S. Tsirkin wrote:
On Mon, Jul 25, 2022 at 11:55:26PM +0300, Andrey Zhadchenko wrote:
Although QEMU virtio-blk is quite fast, there is still some room for
| 110k | 113k |
vhost-blk, 2vcpu | 247k | 252k |
vhost-blk, 4vcpu | 576k | 567k |
Signed-off-by: Andrey Zhadchenko
---
hw/block/Kconfig | 5 +
hw/block/meson.build | 4 +
hw/block/vhost-blk.c | 394
|
Andrey Zhadchenko (1):
block: add vhost-blk backend
configure | 13 ++
hw/block/Kconfig | 5 +
hw/block/meson.build | 1 +
hw/block/vhost-blk.c | 395 ++
hw/virtio/meson.build | 1 +
hw/virtio/vhost-blk
33 matches
Mail list logo
