On 23/12/19 08:43, Vladimir Sementsov-Ogievskiy wrote:
> diff --git a/vl.c b/vl.c
> index 86474a55c9..9fb859969c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2779,7 +2779,7 @@ static void configure_accelerators(const char *progname)
> for (tmp = accel_list; !accel_initialised && tmp && *tmp; tmp
23.12.2019 11:39, Paolo Bonzini wrote:
> On 23/12/19 08:43, Vladimir Sementsov-Ogievskiy wrote:
>> diff --git a/vl.c b/vl.c
>> index 86474a55c9..9fb859969c 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -2779,7 +2779,7 @@ static void configure_accelerators(const char
>> *progname)
>> for (tmp
23.12.2019 12:06, Eiichi Tsukata wrote:
> bdrv_open_driver() allocates bs->opaque according to drv->instance_size.
> There is no need to allocate it and overwrite opaque in
> bdrv_backup_top_append().
>
> Reproducer:
>
>$ QTEST_QEMU_BINARY=./x86_64-softmmu/qemu-system-x86_64 valgrind -q
> --
bdrv_open_driver() allocates bs->opaque according to drv->instance_size.
There is no need to allocate it and overwrite opaque in
bdrv_backup_top_append().
Reproducer:
$ QTEST_QEMU_BINARY=./x86_64-softmmu/qemu-system-x86_64 valgrind -q
--leak-check=full tests/test-replication -p /replication/se
On 2019/12/23 21:40, Vladimir Sementsov-Ogievskiy wrote:
> 23.12.2019 12:06, Eiichi Tsukata wrote:
>> bdrv_open_driver() allocates bs->opaque according to drv->instance_size.
>> There is no need to allocate it and overwrite opaque in
>> bdrv_backup_top_append().
>>
>> Reproducer:
>>
>>$ QTES
From: Stefan Hajnoczi
Virtqueue notifications are not necessary during polling, so we disable
them. This allows the guest driver to avoid MMIO vmexits.
Unfortunately the virtio-blk and virtio-scsi handler functions re-enable
notifications, defeating this optimization.
Fix virtio-blk and virtio-
From: Denis Plotnikov
Before the patch, seg_max parameter was immutable and hardcoded
to 126 (128 - 2) without respect to queue size. This has two negative effects:
1. when queue size is < 128, we have Virtio 1.1 specfication violation:
(2.6.5.3.1 Driver Requirements) seq_max must be <= queue
Fuzzing the Linux kernel with syzkaller allowed to find how to crash qemu
using a special SCSI_IOCTL_SEND_COMMAND. It hits the assertion in
ide_dma_cb() introduced in the commit a718978ed58a in July 2015.
Currently this bug is not reproduced by the unit tests.
Let's improve the ide-test to cover m
Fuzzing the Linux kernel with syzkaller allowed to find how to crash qemu
using a special SCSI_IOCTL_SEND_COMMAND. It hits the assertion in
ide_dma_cb() introduced in the commit a718978ed58a in July 2015.
This patch series fixes incorrect handling of some PRDTs in ide_dma_cb()
and improves the ide
The commit a718978ed58a from July 2015 introduced the assertion which
implies that the size of successful DMA transfers handled in ide_dma_cb()
should be multiple of 512 (the size of a sector). But guest systems can
initiate DMA transfers that don't fit this requirement.
For fixing that let's chec
On 12/19/19 1:36 PM, Max Reitz wrote:
> The "migration completed" event may be sent (on the source, to be
> specific) before the migration is actually completed, so the VM runstate
> will still be "finish-migrate" instead of "postmigrate". So ask the
> users of VM.wait_migration() to specify th
On 12/19/19 9:42 AM, Max Reitz wrote:
> First, driver=qcow2 will not work so well with non-qcow2 formats (and
> this test claims to support qcow, qed, and vmdk).
>
> Second, vmdk will always report the backing file format to be vmdk.
> Filter that out so the output looks like for all other form
On 12/19/19 10:01 AM, Kevin Wolf wrote:
> Am 16.12.2019 um 19:14 hat Alexander Popov geschrieben:
>> The commit a718978ed58a from July 2015 introduced the assertion which
>> implies that the size of successful DMA transfers handled in ide_dma_cb()
>> should be multiple of 512 (the size of a sect
On 24.12.2019 03:20, John Snow wrote:
> On 12/19/19 10:01 AM, Kevin Wolf wrote:
>>
>> John, what do you think?
>>
>
> I've been out to lunch for a little while. There are some issues that I
> recall with IDE, but couldn't find the time to fix prior to 4.2.
Hello John.
> I'll review all the outst
14 matches
Mail list logo