Hi Philippe,
On Fri, Feb 19, 2021 at 2:03 AM Philippe Mathieu-Daudé wrote:
>
> On 2/18/21 6:09 PM, Philippe Mathieu-Daudé wrote:
> > On 2/16/21 4:46 AM, Bin Meng wrote:
> >> The codes to limit the maximum block size is only necessary when
> >> SDHC_BLKSIZE register is writable.
>
> Per "SD
Hi Philippe,
On Fri, Feb 19, 2021 at 2:06 AM Philippe Mathieu-Daudé wrote:
>
> Hi Bin,
>
> On 2/16/21 4:46 AM, Bin Meng wrote:
> > 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
On Sat, Feb 20, 2021 at 6:28 AM Philippe Mathieu-Daudé wrote:
>
> On 2/16/21 4:02 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
There is new interest in the SD/MMC device emulation, so it
would be good to have more than only one maintainer / reviewer
for it.
Bin Meng proved by his contributions a deep understanding of the
SD cards internals, so let's add him to the corresponding section
in the MAINTAINERS file.
From: Bin Meng
These APIs and macros may be referenced by functions that are
currently before them. Move them ahead a little bit.
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20210216150225.27996-5-bmeng...@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé
---
From: Bin Meng
High capacity cards don't support write protection hence we should
not perform the write protect groups check in sd_erase() for them.
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20210216150225.27996-6-bmeng...@gmail.com>
Signed-off-by: Philippe
From: Bin Meng
Unlike SD mode, when SD card is working in SPI mode, the argument
of CMD13 is stuff bits. Hence we should bypass the RCA check.
See "Physical Layer Specification Version 8.00", chapter 7.3.1.3
Detailed Command Description (SPI mode):
"The card shall ignore stuff bits and
From: Bin Meng
s->prnsts is updated in both branches of the if () else () statement.
Move the common bits outside so that it is cleaner.
Signed-off-by: Bin Meng
Tested-by: Alexander Bulekov
Reviewed-by: Alexander Bulekov
Reviewed-by: Philippe Mathieu-Daudé
Message-Id:
From: Bin Meng
Per the "Physical Layer Specification Version 8.00", table 4-26
(SD mode) and table 7-3 (SPI mode) command descriptions, the
following commands:
- CMD28 (SET_WRITE_PROT)
- CMD29 (CLR_WRITE_PROT)
- CMD30 (SEND_WRITE_PROT)
are only supported by SDSC cards.
Signed-off-by: Bin Meng
From: Bin Meng
Per the "Physical Layer Specification Version 8.00", table 4-26
(SD mode) and table 7-3 (SPI mode) command descriptions, CMD30
response type is R1, not R1b.
Fixes: a1bb27b1e98a ("SD card emulation initial implementation")
Signed-off-by: Bin Meng
Reviewed-by: Philippe
From: Bin Meng
For high capacity memory cards, the erase start address and end
address are multiplied by 512, but the address check is still
based on the original block number in sd->erase_{start, end}.
Fixes: 1bd6fd8ed593 ("hw/sd/sdcard: Do not attempt to erase out of range
addresses")
From: Bin Meng
Besides CMD12, the following command's reponse type is R1b:
- SET_WRITE_PROT (CMD28)
- CLR_WRITE_PROT (CMD29)
- ERASE (CMD38)
Reuse the same s->stopping to indicate a R1b reponse is needed.
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id:
From: Bin Meng
Add 2 more states for the block write operation. The SPI host needs
to send a data start token to start the transfer, and the data block
written to the card will be acknowledged by a data response token.
Signed-off-by: Bin Meng
[PMD: Change VMState version id 6 -> 7]
From: Bin Meng
High capacity cards don't support write protection hence we should
not perform the write protect groups check in CMD24/25 for them.
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20210216150225.27996-8-bmeng...@gmail.com>
Signed-off-by: Philippe
From: Bin Meng
The SEND_IF_COND command (CMD8) response is of format R7, but
current code returns R1 for CMD8. Fix it.
Fixes: 775616c3ae8c ("Partial SD card SPI mode support")
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20210128063035.15674-8-bmeng...@gmail.com>
From: Bin Meng
CMD12's response type is R1b, which is basically a R1 plus optional
addition of the busy signal token that can be any number of bytes.
A zero value indicates card is busy and a non-zero value indicates
the card is ready for the next command.
Current implementation sends the busy
From: Bin Meng
At present the single/multiple block write in SPI mode is blocked
by sd_normal_command(). Remove the limitation.
Signed-off-by: Bin Meng
Tested-by: Philippe Mathieu-Daudé
Acked-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Message-Id:
From: Bin Meng
At present there is a data_ready() callback for the SD data read
path. Let's add a receive_ready() for the SD data write path.
Signed-off-by: Bin Meng
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Alistair Francis
Message-Id:
From: Bin Meng
The single block read (CMD17) codes are the same as the multiple
block read (CMD18). Merge them into one. The same applies to single
block write (CMD24) and multiple block write (CMD25).
Signed-off-by: Bin Meng
Tested-by: Philippe Mathieu-Daudé
Acked-by: Alistair Francis
From: Bin Meng
In the case of a multiple block read operation every transferred
block has its suffix of CRC16. Update the state machine logic to
handle multiple block read.
Signed-off-by: Bin Meng
[PMD: Change VMState version id 5 -> 6]
Signed-off-by: Philippe Mathieu-Daudé
Tested-by:
The following changes since commit e90ef02389dc8b57eaea22b290244609d720a8bf:
Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2021-02-18' into
staging (2021-02-19 17:22:42 +)
are available in the Git repository at:
https://gitlab.com/philmd/qemu.git tags/sdmmc-20210220
for
On 2/16/21 2:28 PM, Philippe Mathieu-Daudé wrote:
> There is new interest in the SD/MMC device emulation, so it
> would be good to have more than only one maintainer / reviewer
> for it.
>
> Bin Meng proved by his contributions a deep understanding of the
> SD cards internals, so let's add him to
On 2/16/21 4:46 AM, Bin Meng wrote:
> s->prnsts is updated in both branches of the if () else () statement.
> Move the common bits outside so that it is cleaner.
>
> Signed-off-by: Bin Meng
> ---
>
> (no changes since v1)
>
> hw/sd/sdhci.c | 7 +++
> 1 file changed, 3 insertions(+), 4
On Mon, 15 Feb 2021 at 10:41, Kevin Wolf wrote:
>
> Am 07.12.2020 um 18:20 hat Stefan Hajnoczi geschrieben:
> > v2:
> > * Add abrt handler that terminates qemu-storage-daemon to
> >vhost-user-blk-test. No more orphaned processes on test failure. [Peter]
> > * Fix sector number calculation
On 2/16/21 4:02 PM, Bin Meng wrote:
> From: Bin Meng
>
> This includes several fixes related to erase operation of a SD card.
> Bin Meng (8):
> hw/sd: sd: Fix address check in sd_erase()
> hw/sd: sd: Only SDSC cards support CMD28/29/30
> hw/sd: sd: Fix CMD30 response type
> hw/sd: sd:
On 2/16/21 4:02 PM, Bin Meng wrote:
> From: Bin Meng
>
> High capacity cards don't support write protection hence we should
> not preform the write protect groups check in sd_erase() for them.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - new patch: sd: Skip write protect groups
On 2/16/21 4:02 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
>
> ---
>
> Changes in v2:
> - honor the write protection bits for SDSC
On 2/16/21 4:02 PM, Bin Meng wrote:
> From: Bin Meng
>
> High capacity cards don't support write protection hence we should
> not preform the write protect groups check in CMD24/25 for them.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - new patch: sd: Skip write protect groups
On 2/16/21 4:02 PM, Bin Meng wrote:
> From: Bin Meng
>
> Per the "Physical Layer Specification Version 8.00", table 4-26
> (SD mode) and table 7-3 (SPI mode) command descriptions, CMD30
> response type is R1, not R1b.
>
> Fixes: a1bb27b1e98a ("SD card emulation initial implementation")
>
On 2/19/21 10:42 AM, Eric Blake wrote:
>> To me, data=false looks compatible with NBD_STATE_HOLE. From user point
>> of view, getting same results from qemu-nbd and qemu-img is more
>> important than being more correct about allocation status.
>
> More to the point, here is our inconsistency:
>
On 2/19/21 10:07 AM, Nir Soffer wrote:
> When querying image extents for raw image, qemu-nbd reports holes as
> zero:
>
> $ qemu-nbd -t -r -f raw empty-6g.raw
>
> $ qemu-img map --output json nbd://localhost
> [{ "start": 0, "length": 6442450944, "depth": 0, "zero": true, "data": true,
>
When querying image extents for raw image, qemu-nbd reports holes as
zero:
$ qemu-nbd -t -r -f raw empty-6g.raw
$ qemu-img map --output json nbd://localhost
[{ "start": 0, "length": 6442450944, "depth": 0, "zero": true, "data": true,
"offset": 0}]
$ qemu-img map --output json empty-6g.raw
[{
On 19.02.21 16:33, Max Reitz wrote:
Without any of HEAD^ or HEAD^^ applied, qemu will most likely crash on
the qemu-io invocation, for a variety of immediate reasons. The
underlying problem is generally a use-after-free access into
backup-top's BlockCopyState.
With only HEAD^ applied, qemu-io
When the backup-top node transitions from active to inactive in
bdrv_backup_top_drop(), the BlockCopyState is freed and the filtered
child is removed, so the node effectively becomes unusable.
However, noone told its I/O functions this, so they will happily
continue accessing bs->backing and
The block job holds a reference to the backup-top node (because it is
passed as the main job BDS to block_job_create()). Therefore,
bdrv_backup_top_drop() cannot delete the backup-top node (replacing it
by its child does not affect the job parent, because that has
.stay_at_node set). That is a
Without any of HEAD^ or HEAD^^ applied, qemu will most likely crash on
the qemu-io invocation, for a variety of immediate reasons. The
underlying problem is generally a use-after-free access into
backup-top's BlockCopyState.
With only HEAD^ applied, qemu-io will run into an EIO (which is not
Hi,
After job-finalize, the backup-top node generally stays around. That’s
quite a problem, because its BlockCopyState is already freed then, and
it has no filtered child. We really want the node to be gone.
The only reference that realistically can keep it alive is that of the
backup job
19.02.2021 14:56, Denis V. Lunev wrote:
On 2/16/21 7:45 PM, Vladimir Sementsov-Ogievskiy wrote:
Test support for reading bitmap from parallels image format.
parallels-with-bitmap.bz2 is generated on Virtuozzo by
parallels-with-bitmap.sh
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
19.02.2021 14:47, Denis V. Lunev wrote:
On 2/16/21 7:45 PM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/parallels.h | 6 +-
block/parallels-ext.c | 286 ++
block/parallels.c | 18 +++
On 2/19/21 12:07 PM, Max Reitz wrote:
> On 13.02.21 22:54, Fam Zheng wrote:
>> On 2021-02-11 15:26, Philippe Mathieu-Daudé wrote:
>>> The null-co driver doesn't zeroize buffer in its default config,
>>> because it is designed for testing and tests want to run fast.
>>> However this confuses
Am 19.02.2021 um 13:45 hat Alberto Garcia geschrieben:
> On Fri 19 Feb 2021 01:21:49 PM CET, Kevin Wolf wrote:
> >> log(vm.qmp('object-add', qom_type='throttle-group', id='tg0',
> >> - props={ 'x-bps-total': size }))
> >> + x_bps_total=size))
> >
> > x-bps-total isn't a
On Fri 19 Feb 2021 01:21:49 PM CET, Kevin Wolf wrote:
>> log(vm.qmp('object-add', qom_type='throttle-group', id='tg0',
>> - props={ 'x-bps-total': size }))
>> + x_bps_total=size))
>
> x-bps-total isn't a stable interface, I'd prefer to use limits.
>
> My patch from November
On Fri 19 Feb 2021 01:04:00 PM CET, Max Reitz wrote:
> Two Python syntax nit picks below.
>> ret = vm.qmp('object-add', qom_type='throttle-group', id='tg',
>> - props={'x-bps-read': 4096})
>> + x_bps_read = 4096)
>
> To stay consistent, I think there
On 16.02.21 18:16, Alberto Garcia wrote:
Signed-off-by: Alberto Garcia
---
tests/qemu-iotests/087 | 8 ++--
tests/qemu-iotests/184 | 18 ++
tests/qemu-iotests/218 | 2 +-
tests/qemu-iotests/235 | 2 +-
tests/qemu-iotests/245 | 4 ++--
On 2/16/21 7:45 PM, Vladimir Sementsov-Ogievskiy wrote:
> Test support for reading bitmap from parallels image format.
> parallels-with-bitmap.bz2 is generated on Virtuozzo by
> parallels-with-bitmap.sh
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
On 2/16/21 7:45 PM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/parallels.h | 6 +-
> block/parallels-ext.c | 286 ++
> block/parallels.c | 18 +++
> block/meson.build | 3 +-
> 4 files
On 13.02.21 22:54, Fam Zheng wrote:
On 2021-02-11 15:26, Philippe Mathieu-Daudé wrote:
The null-co driver doesn't zeroize buffer in its default config,
because it is designed for testing and tests want to run fast.
However this confuses security researchers (access to uninit
buffers).
I'm a
Signed-off-by: Akihiko Odaki
---
hw/block/virtio-blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index bac2d6fa2b2..692fd17b0e0 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -965,7 +965,7 @@ static void
This commit introduces "punch hole" operation and optimizes transfer
block size for macOS.
This commit introduces two additional members,
discard_granularity and opt_io to BlockSizes type in
include/block/block.h. Also, the members of the type are now
optional. Set -1 to discard_granularity and 0
Patchew URL:
https://patchew.org/QEMU/20210219085148.90545-1-akihiko.od...@gmail.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210219085148.90545-1-akihiko.od...@gmail.com
Subject: [PATCH] block/file-posix:
50 matches
Mail list logo
