David Gibson writes:
> On Thu, Feb 21, 2019 at 05:31:30PM +0100, Markus Armbruster wrote:
>> Alex Bennée writes:
>>
>> > Markus Armbruster writes:
>> >
>> >> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
>> >> Image size is rounded up to the next multiple of 64KiB.
Philippe Mathieu-Daudé writes:
> On 2/21/19 10:38 AM, Peter Maydell wrote:
>> On Thu, 21 Feb 2019 at 09:22, Markus Armbruster wrote:
>>> Double-checking... you want me to keep goto reset_flash, like this:
>>>
>>> @@ -623,8 +617,8 @@ static void pflash_write(PFlashCFI01 *pfl, hwaddr
>>> offset,
On 2/18/19 4:25 PM, Philippe Mathieu-Daudé wrote:
> On 2/18/19 9:05 PM, Eric Blake wrote:
>> [adding Eduardo for some python 2-vs-3 advice]
>
> And Cleber.
>
>>
>> On 2/18/19 1:59 PM, Andrey Shinkevich wrote:
>>> To write one byte to disk, Python2 may use 'chr' type.
>>> In Python3,
On Thu, Feb 21, 2019, 21:48 Hi,
> Based on oVirt 4.3.0, I have data domain from FC lun, then I create new vm
> on the disk from FC data domain.
> After VM was created. According to qemu-img info, the disk size is 0.
> # qemu-img info
>
On Thu, Feb 21, 2019 at 05:31:30PM +0100, Markus Armbruster wrote:
> Alex Bennée writes:
>
> > Markus Armbruster writes:
> >
> >> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
> >> Image size is rounded up to the next multiple of 64KiB. Useless,
> >> because
On Thu, Feb 21, 2019 at 12:08:12PM -0600, Eric Blake wrote:
> On 2/21/19 11:37 AM, Sergio Lopez wrote:
> > This parameter is analogous to convert's "-C", making use of
> > bdrv_co_copy_range().
>
> The last time I tried to patch 'qemu-img dd', it was pointed out that it
> already has several bugs
Markus Armbruster writes:
> Philippe Mathieu-Daudé writes:
>
>> On 2/21/19 10:38 AM, Peter Maydell wrote:
>>> On Thu, 21 Feb 2019 at 09:22, Markus Armbruster wrote:
Double-checking... you want me to keep goto reset_flash, like this:
@@ -623,8 +617,8 @@ static void
BALATON Zoltan writes:
> On Thu, 21 Feb 2019, Markus Armbruster wrote:
>> Alex Bennée writes:
>>
>>> Markus Armbruster writes:
>>>
QOMification left parameter @size unused in pflash_cfi01_register()
and pflash_cfi02_register(). register(). Obviously, @size should
match
On 2/21/19 11:37 AM, Sergio Lopez wrote:
> This parameter is analogous to convert's "-C", making use of
> bdrv_co_copy_range().
The last time I tried to patch 'qemu-img dd', it was pointed out that it
already has several bugs (where it is not on feature-parity with real
dd), and that we REALLY
This parameter is analogous to convert's "-C", making use of
bdrv_co_copy_range().
Signed-off-by: Sergio Lopez
---
qemu-img-cmds.hx | 4 +-
qemu-img.c | 146 ---
qemu-img.texi| 2 +-
3 files changed, 117 insertions(+), 35 deletions(-)
On Thu, 21 Feb 2019, Markus Armbruster wrote:
Alex Bennée writes:
Markus Armbruster writes:
QOMification left parameter @size unused in pflash_cfi01_register()
and pflash_cfi02_register(). register(). Obviously, @size should
match @sector_len and @nb_blocs, i.e. size == sector_len *
Alex Bennée writes:
> Markus Armbruster writes:
>
>> QOMification left parameter @size unused in pflash_cfi01_register()
>> and pflash_cfi02_register(). register(). Obviously, @size should
>> match @sector_len and @nb_blocs, i.e. size == sector_len * nb_blocs.
>> All callers satisfy this.
>>
Philippe Mathieu-Daudé writes:
> On 2/21/19 10:38 AM, Peter Maydell wrote:
>> On Thu, 21 Feb 2019 at 09:22, Markus Armbruster wrote:
>>> Double-checking... you want me to keep goto reset_flash, like this:
>>>
>>> @@ -623,8 +617,8 @@ static void pflash_write(PFlashCFI01 *pfl, hwaddr
>>> offset,
On 02/21/19 17:39, Philippe Mathieu-Daudé wrote:
> On 2/21/19 1:46 PM, Laszlo Ersek wrote:
>> On 02/21/19 13:38, Peter Maydell wrote:
>>> On Thu, 21 Feb 2019 at 12:07, Laszlo Ersek wrote:
since we're talking "reset_flash", I'll note that there is no actual
reset handler for
Markus Armbruster writes:
> QOMification left parameter @size unused in pflash_cfi01_register()
> and pflash_cfi02_register(). register(). Obviously, @size should
> match @sector_len and @nb_blocs, i.e. size == sector_len * nb_blocs.
> All callers satisfy this.
>
> Remove @nb_blocs and
Thomas Huth writes:
> On 21/02/2019 14.41, Alex Bennée wrote:
>> We are seeing instability on our CI runs which has been there since
>> the test was introduced. I suspect it triggers more on Travis due to
>> their heavy load.
>>
>> Signed-off-by: Alex Bennée
>> ---
>> tests/cdrom-test.c | 10
On 2/21/19 10:15 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> On 2/19/19 2:41 PM, Markus Armbruster wrote:
>>> Philippe Mathieu-Daudé writes:
>>>
On 2/18/19 1:56 PM, Markus Armbruster wrote:
> flash.h's incomplete struct pflash_t is completed both in
>
On 2/21/19 1:46 PM, Laszlo Ersek wrote:
> On 02/21/19 13:38, Peter Maydell wrote:
>> On Thu, 21 Feb 2019 at 12:07, Laszlo Ersek wrote:
>>> since we're talking "reset_flash", I'll note that there is no actual
>>> reset handler for cfi.pflash01. I found out recently, via:
>>>
>>>
Alex Bennée writes:
> Markus Armbruster writes:
>
>> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
>> Image size is rounded up to the next multiple of 64KiB. Useless,
>> because pflash_cfi02_realize() fails with "failed to read the initial
>> flash content" unless the
On 21/02/2019 14.41, Alex Bennée wrote:
> We are seeing instability on our CI runs which has been there since
> the test was introduced. I suspect it triggers more on Travis due to
> their heavy load.
>
> Signed-off-by: Alex Bennée
> ---
> tests/cdrom-test.c | 10 --
> 1 file changed, 8
On 21/02/2019 14.00, Alex Bennée wrote:
>
> Thomas Huth writes:
>
>> On 20/02/2019 21.52, Alex Bennée wrote:
>>>
>>> Alex Bennée writes:
>>>
Hi,
tests/boot-sector.c:161:boot_sector_test:
assertion failed (signature == SIGNATURE): (0xface == 0xdead)
I
On 2/21/19 10:38 AM, Peter Maydell wrote:
> On Thu, 21 Feb 2019 at 09:22, Markus Armbruster wrote:
>> Double-checking... you want me to keep goto reset_flash, like this:
>>
>> @@ -623,8 +617,8 @@ static void pflash_write(PFlashCFI01 *pfl, hwaddr offset,
>> pfl->wcycle = 0;
>>
Markus Armbruster writes:
> QOMification left parameter @qdev unused in pflash_cfi01_register()
> and pflash_cfi02_register(). All callers pass NULL. Remove.
>
> Signed-off-by: Markus Armbruster
Reviewed-by: Alex Bennée
> ---
> hw/arm/collie.c | 4 ++--
>
From: mahaocong
This patch adds possibility to start mirroring with user-created-bitmap.
On full mode, mirror create a non-named-bitmap by scanning whole block-chain,
and on top mode, mirror create a bitmap by scanning the top block layer. So I
think I can copy a user-created-bitmap and use it
The test case TestParallelOps::test_stream_parallel in #030 fails
if a base node is protected by the block-stream running job that
includes the base node into the job node list (block_job_add_bdrv)
without BLK_PERM_GRAPH_MOD shared permission.
The block-stream job would own the base node not
The block-stream job needs to own the base node as the limiter
of the copy-on-read operation. So, the base node is included in
the job node list (block_job_add_bdrv).
Also, the block-stream job would not allow the base node to go
away due to the graph modification, e.g. when a filter node is
The block-stream job needs to own the base node as the limiter for
the copy-on-read operation. So, the base node is included in the
job node list by calling to the function block_job_add_bdrv().
Also, the block-stream job would not allow the base node to go
away due to the graph modification, e.g.
Markus Armbruster writes:
> pflash_cfi01_register() takes a size in bytes, a block size in bytes
> and a number of blocks. mips_malta_init() passes BIOS_SIZE, 65536,
> FLASH_SIZE >> 16. Actually consistent only because BIOS_SIZE (defined
> in include/hw/mips/bios.h as (4 * MiB)) matches
Markus Armbruster writes:
> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
> Image size is rounded up to the next multiple of 64KiB. Useless,
> because pflash_cfi02_realize() fails with "failed to read the initial
> flash content" unless the rounding is a no-op.
>
> If
Markus Armbruster writes:
> We have two open-coded copies of macro CFI_PFLASH01(). Move the macro
> to the header, so we can ditch the copies. Move CFI_PFLASH02() to the
> header for symmetry.
>
> We define macros TYPE_CFI_PFLASH01 and TYPE_CFI_PFLASH02 for type name
> strings, then mostly
Markus Armbruster writes:
> Markus Armbruster writes:
>
>> Peter Maydell writes:
>>
>>> On Tue, 19 Feb 2019 at 12:41, Philippe Mathieu-Daudé
>>> wrote:
On 2/18/19 1:56 PM, Markus Armbruster wrote:
> PFLASH_BUG()'s lone use has a suspicious smell: it prints "Possible
>
Markus Armbruster writes:
> flash.h's incomplete struct pflash_t is completed both in
> pflash_cfi01.c and in pflash_cfi02.c. The complete types are
> incompatible. This can hide type errors, such as passing a pflash_t
> created with pflash_cfi02_register() to pflash_cfi01_get_memory().
>
>
(sorry I accidentally sent an incomplete reply a few minutes ago)
On Tue 12 Feb 2019 06:27:56 PM CET, Kevin Wolf wrote:
>> - In bdrv_reopen_commit(): perform the actual node replacement by
>>calling bdrv_set_backing_hd(). It may happen that there are
>>temporary implicit nodes between
On Tue 12 Feb 2019 06:27:56 PM CET, Kevin Wolf wrote:
>> - In bdrv_reopen_commit(): perform the actual node replacement by
>>calling bdrv_set_backing_hd(). It may happen that there are
>>temporary implicit nodes between the BDS that we are reopening and
>>the backing file that we want
On 02/21/19 13:38, Peter Maydell wrote:
> On Thu, 21 Feb 2019 at 12:07, Laszlo Ersek wrote:
>> since we're talking "reset_flash", I'll note that there is no actual
>> reset handler for cfi.pflash01. I found out recently, via:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1678713
>
> Yes;
Anton Nefedov writes:
> On 13/12/2018 3:20 PM, Markus Armbruster wrote:
>> I'm reviewing just the QAPI schema today.
>>
>> Anton Nefedov writes:
>>
>>> A block driver can provide a callback to report driver-specific
>>> statistics.
>>>
>>> file-posix driver now reports discard statistics
>>>
On Thu, 21 Feb 2019 at 12:07, Laszlo Ersek wrote:
> since we're talking "reset_flash", I'll note that there is no actual
> reset handler for cfi.pflash01. I found out recently, via:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1678713
Yes; this isn't uncommon for some of the really old
device
somewhat off-topic:
On 02/21/19 10:38, Peter Maydell wrote:
> On Thu, 21 Feb 2019 at 09:22, Markus Armbruster wrote:
>> Double-checking... you want me to keep goto reset_flash, like this:
>>
>> @@ -623,8 +617,8 @@ static void pflash_write(PFlashCFI01 *pfl, hwaddr offset,
>>
Hi Stefan,
I can confirm that the symbols are included in the binary using gdb.
I will send you and Paolo an email with the link and credentials (if needed) so
you can download everything.
Thanks!
On jue, feb 21, 2019 at 12:11 PM, Stefan Hajnoczi wrote:
On Wed, Feb 20, 2019 at 06:56:04PM
On Wed, Feb 20, 2019 at 06:56:04PM +, Fernando Casas Schössow wrote:
> Regarding the dumps I have three of them including guest memory, 2 for
> virtio-scsi, 1 for virtio-blk, in case a comparison may help to confirm which
> is the proble.) I can upload them to a server you indicate me or I
From: yuchenlin
In vmdk_co_create_opts, when it finds hw_version is undefined, it will
set it to 4, which misleading the compat6 and hwversion in
vmdk_co_do_create. Simply set hw_version to NULL after free, let
the logic in vmdk_co_do_create to decide the value of hw_version.
This bug can be
On Wed, Feb 20, 2019 at 01:03:58PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> We have a very frequent pattern of creating coroutine from function
> with several arguments:
>
> - create structure to pack parameters
> - create _entry function to call original function taking
This function is useful to fix the endianness of struct
virtio_blk_discard_write_zeroes headers.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git
Starting from DISABLE and WRITE_ZEROES features, we use an array of
VirtIOFeature (as virtio-net) to properly set the config size
depending on the features enabled.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
---
hw/block/virtio-blk.c | 31
In order to use VirtIOFeature also in other virtio devices, we move
its declaration and the endof() macro (renamed in virtio_endof())
in virtio.h.
We add virtio_feature_get_config_size() function to iterate the array
of VirtIOFeature and to return the config size depending on the
features enabled.
In order to avoid migration issues, we enable DISCARD and
WRITE_ZEROES features only for machine type >= 4.0
As discussed with Michael S. Tsirkin and Stefan Hajnoczi on the
list [1], DISCARD operation should not have security implications
(eg. page cache attacks), so we can enable it by default.
This patch adds the support of DISCARD and WRITE_ZEROES commands,
that have been introduced in the virtio-blk protocol to have
better performance when using SSD backend.
We support only one segment per request since multiple segments
are not widely used and there are no userspace APIs that allow
If the DISCARD feature is enabled, we try this command in the
test_basic(), checking only the status returned by the request.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 27 +++
1 file changed, 27 insertions(+)
diff
If the WRITE_ZEROES feature is enabled, we check this command
in the test_basic().
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Acked-by: Thomas Huth
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 62 +
1 file changed,
The size of data in the virtio_blk_request must be a multiple
of 512 bytes for IN and OUT requests, or a multiple of the size
of struct virtio_blk_discard_write_zeroes for DISCARD and
WRITE_ZEROES requests.
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Thomas Huth
This series adds the support of DISCARD and WRITE_ZEROES commands
and extends the virtio-blk-test to test these new commands.
v6:
- fixed patchew failure on patch 8 (do not initialise globals to 0 or NULL)
- added R-b tags by Stefan
v5:
- rebased on master
- handled the config size for DISCARD
We add acct_failed param in order to use virtio_blk_handle_rw_error()
also when is not required to call block_acct_failed(). (eg. a discard
operation is failed)
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
---
hw/block/virtio-blk.c | 10
Since configurable features for virtio-blk are growing, this patch
adds host_features field in the struct VirtIOBlock. (as in virtio-net)
In this way, we can avoid to add new fields for new properties and
we can directly set VIRTIO_BLK_F* flags in the host_features.
We update "config-wce" and
On 21/02/2019 11.11, Stefan Hajnoczi wrote:
> Test 238 does not require the kvm accelerator. TCG works fine.
>
> Use the default accelerator instead of requiring kvm.
>
> Suggested-by: Thomas Huth
> Signed-off-by: Stefan Hajnoczi
> ---
> Vladimir, I have dropped the 235 change because I don't
Test 238 does not require the kvm accelerator. TCG works fine.
Use the default accelerator instead of requiring kvm.
Suggested-by: Thomas Huth
Signed-off-by: Stefan Hajnoczi
---
Vladimir, I have dropped the 235 change because I don't have time to
figure out the kvm/tcg vs qtest differences or
On Thu, 21 Feb 2019 at 09:22, Markus Armbruster wrote:
> Double-checking... you want me to keep goto reset_flash, like this:
>
> @@ -623,8 +617,8 @@ static void pflash_write(PFlashCFI01 *pfl, hwaddr offset,
> pfl->wcycle = 0;
> pfl->status |= 0x80;
>
Markus Armbruster writes:
> Peter Maydell writes:
>
>> On Tue, 19 Feb 2019 at 12:41, Philippe Mathieu-Daudé
>> wrote:
>>>
>>> On 2/18/19 1:56 PM, Markus Armbruster wrote:
>>> > PFLASH_BUG()'s lone use has a suspicious smell: it prints "Possible
>>> > BUG", which sounds like a warning, then
Philippe Mathieu-Daudé writes:
> On 2/19/19 2:41 PM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>
>>> On 2/18/19 1:56 PM, Markus Armbruster wrote:
flash.h's incomplete struct pflash_t is completed both in
pflash_cfi01.c and in pflash_cfi02.c. The complete types are
Am 20.02.2019 um 19:22 hat Paolo Bonzini geschrieben:
> On 20/02/19 19:07, Kevin Wolf wrote:
> > Am 20.02.2019 um 19:01 hat Paolo Bonzini geschrieben:
> >> aio_co_wake was also acquiring/releasing the AioContext, so
> >> that needs to stay for now.
> >
> > True. Maybe I should leave the
On 14/1/2019 2:18 PM, Anton Nefedov wrote:
> This pull request is to start to improve a few performance points of
> qcow2 format:
>
>1. non cluster-aligned write requests (to unallocated clusters) explicitly
> pad data with zeroes if there is no backing data.
> Resulting increase
60 matches
Mail list logo
