Kdy si muzem cinknout k dalsimu vyvoji?
Odesláno z iPhonu
> 22. 3. 2021 v 12:37, Patrik Janoušek :
>
>
>> On 3/22/21 12:18 PM, Vladimir Sementsov-Ogievskiy wrote:
>> 22.03.2021 13:46, Vladimir Sementsov-Ogievskiy wrote:
>>> 22.03.2021 13:18, Patrik Janoušek wrote:
On 3/22/21 9:41 AM,
I'm mostly happy with this. My biggest overall comment is that I think
this should be split into two, as your refactor using different event
handlers for init is a standalone improvement over and above the bugfix.
I would have the first commit split out vhost_user_blk_event_init() and
On 3/17/21 3:00 AM, Olaf Hering wrote:
Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
Xen HVM domUs which run xenlinux based kernels.
If the domU has an USB device assigned, for example with
"usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
kill the
On 3/22/21 1:06 PM, Max Reitz wrote:
> On 22.03.21 12:27, Patrik Janoušek wrote:
>> On 3/22/21 11:48 AM, Max Reitz wrote:
>>> Hi,
>>>
>>> On 20.03.21 11:01, Patrik Janoušek wrote:
I'm sorry, but I forgot to add you to the cc, so I'm forwarding the
patch to you additionally. I don't want
On Mar 18 12:11, Daniel P. Berrangé wrote:
> On Thu, Mar 18, 2021 at 01:01:58PM +0100, Klaus Jensen wrote:
> > On Mar 18 11:28, Peter Maydell wrote:
> > > On Thu, 18 Mar 2021 at 11:27, Klaus Jensen wrote:
> > > >
> > > > On Mar 18 11:26, Peter Maydell wrote:
> > > > > On Tue, 16 Mar 2021 at
Let's document how we use file locks in file-posix driver, to allow
external programs to "communicate" in this way with Qemu.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Hi all!
We need to access disk images from non-Qemu code and coordinate with
Qemu utilities which may use same image.
Laurent Vivier writes:
> Tests are executed using virtio-*-pci even on a non PCI machine..
> .
> The problem can be easily fixed using the virtio aliases.
> (virtio-*), to run virtio-*-ccw on s390x and virtio-*-device on.
> m68k..
> .
> A first attempt was tried with virtio-*-ccw by detecting.
On 3/22/21 5:25 AM, ChangLimin wrote:
For Linux 5.10/5.11, qemu write zeros to a multipath device using
ioctl(fd, BLKZEROOUT, range) with cache none or directsync return -EBUSY
permanently. Fallback to pwritev instead of exit for -EBUSY error.
The issue was introduced in Linux 5.10:
On Mon, Mar 15, 2021 at 11:03 AM Joelle van Dyne wrote:
>
> On Darwin (iOS), there are no system level APIs for directly accessing
> host block devices. We detect this at configure time.
>
> Signed-off-by: Joelle van Dyne
Hi all, this is the last patch in this set that has to be reviewed. I
was
From: Bin Meng
If the block size is programmed to a different value from the
previous one, reset the data pointer of s->fifo_buffer[] so that
s->fifo_buffer[] can be filled in using the new block size in
the next transfer.
With this fix, the following reproducer:
outl 0xcf8 0x80001010
outl
From: Bin Meng
When an ADMA transfer is started, the codes forget to set the
controller status to indicate a transfer is in progress.
With this fix, the following 2 reproducers:
https://paste.debian.net/plain/1185136
https://paste.debian.net/plain/1185141
cannot be reproduced with the
From: Bin Meng
Per "SD Host Controller Standard Specification Version 7.00"
chapter 2.2.1 SDMA System Address Register:
This register can be accessed only if no transaction is executing
(i.e., after a transaction has stopped).
With this fix, the following reproducer:
outl 0xcf8 0x80001010
From: Bin Meng
The codes to limit the maximum block size is only necessary when
SDHC_BLKSIZE register is writable.
Tested-by: Alexander Bulekov
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Bin Meng
Message-Id: <20210303122639.20004-5-bmeng...@gmail.com>
Signed-off-by: Philippe
From: Bin Meng
At the end of sdhci_send_command(), it starts a data transfer if the
command register indicates data is associated. But the data transfer
should only be initiated when the command execution has succeeded.
With this fix, the following reproducer:
outl 0xcf8 0x80001810
outl 0xcfc
From: Bin Meng
At present the sd_erase() does not erase the requested range of card
data to 0xFFs. Let's make the erase operation actually happen.
Signed-off-by: Bin Meng
Message-Id: <1613811493-58815-1-git-send-email-bmeng...@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by:
From: Bin Meng
"qemu-common.h" should be included to provide the forward declaration
of qemu_hexdump() when DEBUG_SD is on.
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20210228050609.24779-1-bmeng...@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé
---
The following changes since commit b184750926812cb78ac0caf4c4b2b13683b5bde3:
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into
staging (2021-03-22 11:24:55 +)
are available in the Git repository at:
https://github.com/philmd/qemu.git tags/sdmmc-20210322
On 3/3/21 1:26 PM, Bin Meng wrote:
> This series includes several fixes to CVE-2020-17380, CVE-2020-25085
> and CVE-2021-3409 that are heap-based buffer overflow issues existing
> in the sdhci model.
>
> These CVEs are pretty much similar, and were filed using different
> reproducers. With this
On Mon, Mar 22, 2021 at 12:49:04PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi all! Accidentally we found on use-after-free. Normally user should
> not remove bitmaps during migration.. But some wrong user actions may
> simply lead to Qemu crash and that's not good.
>
> Vladimir
On Sat, Mar 6, 2021 at 1:02 AM Bin Meng wrote:
>
> From: Bin Meng
>
> Per SST25VF016B datasheet [1], SST flash requires a dummy byte after
> the address bytes. Note only SPI mode is supported by SST flashes.
>
> [1] http://ww1.microchip.com/downloads/en/devicedoc/s71271_04.pdf
>
> Signed-off-by:
On 08/03/2021 14:32, Anthony PERARD wrote:
From: Anthony PERARD
Whenever a Xen block device is detach via xenstore, the image
associated with it remained open by the backend QEMU and an error is
logged:
qemu-system-i386: failed to destroy drive: Node xvdz-qcow2 is in use
This happened
On 3/10/21 8:16 AM, Bin Meng wrote:
> Hi Philippe,
>
> On Sat, Feb 20, 2021 at 4:58 PM Bin Meng wrote:
>>
>> From: Bin Meng
>>
>> At present the sd_erase() does not erase the requested range of card
>> data to 0xFFs. Let's make the erase operation actually happen.
>>
>> Signed-off-by: Bin Meng
Hi Paul, Stefano,
Could one of you could give a Ack to this patch?
Thanks,
On Mon, Mar 08, 2021 at 02:32:32PM +, Anthony PERARD wrote:
> From: Anthony PERARD
>
> Whenever a Xen block device is detach via xenstore, the image
> associated with it remained open by the backend QEMU and an
On 2/28/21 6:06 AM, Bin Meng wrote:
> From: Bin Meng
>
> "qemu-common.h" should be included to provide the forward declaration
> of qemu_hexdump() when DEBUG_SD is on.
>
> Signed-off-by: Bin Meng
> ---
>
> hw/sd/sd.c | 1 +
> 1 file changed, 1 insertion(+)
Thanks, patch applied to
On Mar 22 14:10, Philippe Mathieu-Daudé wrote:
> On 3/22/21 1:37 PM, Klaus Jensen wrote:
> > On Mar 22 10:58, Philippe Mathieu-Daudé wrote:
> >> On 3/22/21 9:24 AM, Joelle van Dyne wrote:
> >>> The check for `n->namespace.blkconf.blk` always fails because
> >>> this is in the initialization
On 3/22/21 1:37 PM, Klaus Jensen wrote:
> On Mar 22 10:58, Philippe Mathieu-Daudé wrote:
>> On 3/22/21 9:24 AM, Joelle van Dyne wrote:
>>> The check for `n->namespace.blkconf.blk` always fails because
>>> this is in the initialization function.
>>
>> This usually mean the code depends to some
On 3/22/21 11:48 AM, Max Reitz wrote:
> Hi,
>
> On 20.03.21 11:01, Patrik Janoušek wrote:
>> I'm sorry, but I forgot to add you to the cc, so I'm forwarding the
>> patch to you additionally. I don't want to spam the mailing list
>> unnecessarily.
>
> I think it’s better to still CC the list. It’s
On 3/22/21 12:18 PM, Vladimir Sementsov-Ogievskiy wrote:
> 22.03.2021 13:46, Vladimir Sementsov-Ogievskiy wrote:
>> 22.03.2021 13:18, Patrik Janoušek wrote:
>>> On 3/22/21 9:41 AM, Vladimir Sementsov-Ogievskiy wrote:
20.03.2021 12:32, Patrik Janoušek wrote:
> Current implementation of
On March 22, 2021 12:27 pm, Patrik Janoušek wrote:
> On 3/22/21 11:48 AM, Max Reitz wrote:
>> Hi,
>>
>> On 20.03.21 11:01, Patrik Janoušek wrote:
>>> I'm sorry, but I forgot to add you to the cc, so I'm forwarding the
>>> patch to you additionally. I don't want to spam the mailing list
>>>
On Mar 22 10:58, Philippe Mathieu-Daudé wrote:
> On 3/22/21 9:24 AM, Joelle van Dyne wrote:
> > The check for `n->namespace.blkconf.blk` always fails because
> > this is in the initialization function.
>
> This usually mean the code depends to some state only available
> during the QOM
22.03.2021 12:49, Vladimir Sementsov-Ogievskiy wrote:
Hi all! Accidentally we found on use-after-free. Normally user should
not remove bitmaps during migration.. But some wrong user actions may
simply lead to Qemu crash and that's not good.
Vladimir Sementsov-Ogievskiy (2):
From: Klaus Jensen
Max noticed that since blk_aio_pwrite_zeroes() may invoke the callback
before returning, the callbacks will never see *count == 0 and thus
never free the count variable or decrement num_formats causing a CQE to
never be posted.
Coverity (CID 1451082) also picked up on the
On 22.03.21 12:27, Patrik Janoušek wrote:
On 3/22/21 11:48 AM, Max Reitz wrote:
Hi,
On 20.03.21 11:01, Patrik Janoušek wrote:
I'm sorry, but I forgot to add you to the cc, so I'm forwarding the
patch to you additionally. I don't want to spam the mailing list
unnecessarily.
I think it’s
From: Klaus Jensen
Fix two issues reported by coverity (CID 1451080 and 1451082).
v2:
- replace [2/2] with a fix for the bad reference counting noticed by
Max
Klaus Jensen (2):
hw/block/nvme: fix resource leak in nvme_dif_rw
hw/block/nvme: fix ref counting in nvme_format_ns
From: Klaus Jensen
If nvme_map_dptr() fails, nvme_dif_rw() will leak the bounce context.
Fix this by using the same error handling as everywhere else in the
function.
Reported-by: Coverity (CID 1451080)
Fixes: 146f720c5563 ("hw/block/nvme: end-to-end data protection")
Signed-off-by: Klaus
22.03.2021 14:28, Stefan Hajnoczi wrote:
On Fri, Mar 19, 2021 at 11:41:22PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
Bitmaps on source are marked busy during migration.
Enabled bitmaps on target have successor, so they are busy.
But disabled migrated bitmaps are not protected on
On Fri, Mar 19, 2021 at 11:41:22PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Bitmaps on source are marked busy during migration.
>
> Enabled bitmaps on target have successor, so they are busy.
>
> But disabled migrated bitmaps are not protected on target. User can
> simple remove
22.03.2021 13:46, Vladimir Sementsov-Ogievskiy wrote:
22.03.2021 13:18, Patrik Janoušek wrote:
On 3/22/21 9:41 AM, Vladimir Sementsov-Ogievskiy wrote:
20.03.2021 12:32, Patrik Janoušek wrote:
Current implementation of dirty bitmaps for raw format is very
limited, because those bitmaps cannot
On 22.03.21 11:48, Klaus Jensen wrote:
On Mar 22 11:02, Max Reitz wrote:
On 22.03.21 07:19, Klaus Jensen wrote:
From: Klaus Jensen
In nvme_format_ns(), if the namespace is of zero size (which might be
useless, but not invalid), the `count` variable will leak. Fix this by
returning early in
On Mar 22 11:02, Max Reitz wrote:
> On 22.03.21 07:19, Klaus Jensen wrote:
> > From: Klaus Jensen
> >
> > In nvme_format_ns(), if the namespace is of zero size (which might be
> > useless, but not invalid), the `count` variable will leak. Fix this by
> > returning early in that case.
>
> When
Hi,
On 20.03.21 11:01, Patrik Janoušek wrote:
I'm sorry, but I forgot to add you to the cc, so I'm forwarding the
patch to you additionally. I don't want to spam the mailing list
unnecessarily.
I think it’s better to still CC the list. It’s so full of mail, one
more won’t hurt. :)
On 22.03.21 07:19, Klaus Jensen wrote:
From: Klaus Jensen
In nvme_format_ns(), if the namespace is of zero size (which might be
useless, but not invalid), the `count` variable will leak. Fix this by
returning early in that case.
When looking at the Coverity report, something else caught my
On 3/22/21 9:24 AM, Joelle van Dyne wrote:
> The check for `n->namespace.blkconf.blk` always fails because
> this is in the initialization function.
This usually mean the code depends to some state only available
during the QOM 'realization' step, so this code should be in
nvme_realize(). Maybe
Incoming enabled bitmaps are busy, because we do
bdrv_dirty_bitmap_create_successor() for them. But disabled bitmaps
being migrated are not marked busy, and user can remove them during the
incoming migration. Then we may crash in cancel_incoming_locked() when
try to remove the bitmap that was
Check that we can't remove bitmaps being migrated on destination vm.
The new check proves that previous commit helps.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/tests/migrate-bitmaps-postcopy-test | 10 ++
1 file changed, 10 insertions(+)
diff --git
Hi all! Accidentally we found on use-after-free. Normally user should
not remove bitmaps during migration.. But some wrong user actions may
simply lead to Qemu crash and that's not good.
Vladimir Sementsov-Ogievskiy (2):
migration/block-dirty-bitmap: make incoming disabled bitmaps busy
For Linux 5.10/5.11, qemu write zeros to a multipath device using
ioctl(fd, BLKZEROOUT, range) with cache none or directsync return -EBUSY
permanently. Fallback to pwritev instead of exit for -EBUSY error.
The issue was introduced in Linux 5.10:
From: Coiby Xu
This test case has the same tests as tests/virtio-blk-test.c except for
tests have block_resize. Since the vhost-user-blk export only serves one
client one time, two exports are started by qemu-storage-daemon for the
hotplug test.
Suggested-by: Thomas Huth
Signed-off-by: Coiby
These patches add a qtest for the vhost-user-blk server. CI found several
issues that caused these patches to be dropped from Michael Tsirkin and Kevin
Wolf's pull requests in the past. Hopefully they will go in smoothly this time!
Coiby Xu (1):
test: new qTest case to test the
Exercise input validation code paths in
block/export/vhost-user-blk-server.c.
Signed-off-by: Stefan Hajnoczi
Message-Id: <20210309094106.196911-5-stefa...@redhat.com>
Signed-off-by: Kevin Wolf
---
tests/qtest/vhost-user-blk-test.c | 124 ++
1 file changed, 124
Signed-off-by: Stefan Hajnoczi
Message-Id: <20210309094106.196911-4-stefa...@redhat.com>
Signed-off-by: Kevin Wolf
---
tests/qtest/vhost-user-blk-test.c | 81 +--
1 file changed, 76 insertions(+), 5 deletions(-)
diff --git a/tests/qtest/vhost-user-blk-test.c
The check for `n->namespace.blkconf.blk` always fails because
this is in the initialization function.
Signed-off-by: Joelle van Dyne
---
hw/block/nvme.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 6842b01ab5..42605fc55d
ping!
On 11.03.2021 11:10, Denis Plotnikov wrote:
Commit a1a20d06b73e "vhost-user-blk: delay vhost_user_blk_disconnect"
introduced postponing vhost_dev cleanup aiming to eliminate qemu aborts
because of connection problems with vhost-blk daemon.
However, it introdues a new problem. Now, any
From: Klaus Jensen
If nvme_map_dptr() fails, nvme_dif_rw() will leak the bounce context.
Fix this by using the same error handling as everywhere else in the
function.
Reported-by: Coverity (CID 1451080)
Fixes: 146f720c5563 ("hw/block/nvme: end-to-end data protection")
Signed-off-by: Klaus
On Mar 18 23:03, Peter Maydell wrote:
> On Thu, 18 Mar 2021 at 11:58, Klaus Jensen wrote:
> >
> > From: Klaus Jensen
> >
> > Hi Peter,
> >
> > The following changes since commit b12498fc575f2ad30f09fe78badc7fef526e2d76:
> >
> > Merge remote-tracking branch
> >
From: Klaus Jensen
Fix two issues reported by coverity (CID 1451080 and 1451082).
Klaus Jensen (2):
hw/block/nvme: fix resource leak in nvme_dif_rw
hw/block/nvme: fix resource leak in nvme_format_ns
hw/block/nvme-dif.c | 2 +-
hw/block/nvme.c | 5 +
2 files changed, 6
From: Klaus Jensen
In nvme_format_ns(), if the namespace is of zero size (which might be
useless, but not invalid), the `count` variable will leak. Fix this by
returning early in that case.
Reported-by: Coverity (CID 1451082)
Fixes: dc04d25e2f3f ("hw/block/nvme: add support for the format nvm
57 matches
Mail list logo
