Eduardo Habkost writes:
> On Wed, Aug 05, 2020 at 09:41:25PM +0100, Peter Maydell wrote:
>> On Wed, 5 Aug 2020 at 20:49, Eduardo Habkost wrote:
>> >
>> > The struct had a single field (IDEDevice dev), and is only used
>> > in the QOM type declarations and property lists. We can simply
>> > use
Eduardo Habkost writes:
> On Wed, Aug 05, 2020 at 06:23:23PM +0200, Kevin Wolf wrote:
>> We're basically weighing "git blame" against syntax highlighting
>> defaults. I don't think the latter has an obviously higher weight.
>
> I think "syntax highlight defaults" is far from being an accurate
>
John Snow writes:
> On 8/5/20 3:36 AM, Markus Armbruster wrote:
>> John Snow writes:
>>
>>> On 8/4/20 4:03 AM, Markus Armbruster wrote:
The pain of tweaking the parser is likely dwarved several times over by
the pain of the flag day.
>>>
>>> You mention this often; I wonder if I
On Wed, Aug 05, 2020 at 09:41:25PM +0100, Peter Maydell wrote:
> On Wed, 5 Aug 2020 at 20:49, Eduardo Habkost wrote:
> >
> > The struct had a single field (IDEDevice dev), and is only used
> > in the QOM type declarations and property lists. We can simply
> > use the IDEDevice struct directly
block/vhdx uses qemu block layer where sector size is always 512 byte.
This may have issues with 4K logical sector sized vhdx image.
For e.g qemu-img convert on such images fails with following assert:
$qemu-img convert -f vhdx -O raw 4KTest1.vhdx test.raw
qemu-img: util/iov.c:388: qiov_slice:
On Wed, 5 Aug 2020 at 20:49, Eduardo Habkost wrote:
>
> The struct had a single field (IDEDevice dev), and is only used
> in the QOM type declarations and property lists. We can simply
> use the IDEDevice struct directly instead.
>
> Signed-off-by: Eduardo Habkost
> @@ -327,7 +323,6 @@ static
The struct had a single field (IDEDevice dev), and is only used
in the QOM type declarations and property lists. We can simply
use the IDEDevice struct directly instead.
Signed-off-by: Eduardo Habkost
---
hw/ide/qdev.c | 25 +
1 file changed, 9 insertions(+), 16
30.07.2020 17:15, Andrey Shinkevich wrote:
Extend the test case #303 by dumping QCOW2 image metadata in JSON
format.
Signed-off-by: Andrey Shinkevich
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
30.07.2020 17:15, Andrey Shinkevich wrote:
Implementation of dumping QCOW2 image metadata.
The sample output:
{
"Header_extensions": [
{
"name": "Feature table",
"magic": 1745090647,
"length": 192,
"data_str": ""
},
Hi Max,
Thanks for the response.
I checked internally and looks like it always fails.
Also in the code I see comment saying "We only support 512 currently"
at block/vhdx.c: vhdx_parse_metadata()
As you suggested we can just refuse to open images with 4K logical sector size,
I will send an
30.07.2020 17:15, Andrey Shinkevich wrote:
As __dict__ is being extended with class members we do not want to
print, add the to_dict() method to classes that returns a dictionary
with desired fields and their values. Extend it in subclass when
necessary to print the final dictionary in the JSON
On Wed, Aug 05, 2020 at 06:23:23PM +0200, Kevin Wolf wrote:
> Am 05.08.2020 um 12:08 hat Daniel P. Berrangé geschrieben:
> > On Wed, Aug 05, 2020 at 11:11:55AM +0200, Cornelia Huck wrote:
> > > On Wed, 5 Aug 2020 10:05:40 +0100
> > > Daniel P. Berrangé wrote:
> > >
> > > > On Wed, Aug 05, 2020
On 05/08/20 12:00, Stefan Hajnoczi wrote:
> +
> +/*
> + * aio_notify can avoid the expensive event_notifier_set if
> + * everything (file descriptors, bottom halves, timers) will
> + * be re-evaluated before the next blocking poll(). This is
> + * already
On 05/08/20 12:00, Stefan Hajnoczi wrote:
> aio_notify() does not set ctx->notified when called with
> ctx->aio_notify_me disabled. Therefore aio_notify_me needs to be enabled
> during polling.
>
> This is suboptimal since expensive event_notifier_set(>notifier)
> and
Am 05.08.2020 um 12:08 hat Daniel P. Berrangé geschrieben:
> On Wed, Aug 05, 2020 at 11:11:55AM +0200, Cornelia Huck wrote:
> > On Wed, 5 Aug 2020 10:05:40 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> > > > On 05/08/20 10:39,
30.07.2020 17:15, Andrey Shinkevich wrote:
Add the command key to the qcow2.py arguments list to dump QCOW2
metadata in JSON format. Here is the suggested way to do that. The
implementation of the dump in JSON format is in the patch that follows.
Signed-off-by: Andrey Shinkevich
Reviewed-by:
On 8/5/20 3:36 AM, Markus Armbruster wrote:
John Snow writes:
On 8/4/20 4:03 AM, Markus Armbruster wrote:
The pain of tweaking the parser is likely dwarved several times over by
the pain of the flag day.
You mention this often; I wonder if I misunderstand the critique,
because the pain of
30.07.2020 17:15, Andrey Shinkevich wrote:
Add bitmap table information to the QCOW2 metadata dump.
Bitmap name bitmap-1
...
Bitmap table typesize offset
0 serialized 6553610092544
1 all-zeroes 655360
For
On Wed, 5 Aug 2020 at 10:24, Tuguoyi wrote:
>
> When calculating the offset, the result of left shift operation will be
> promoted
> to type int64 automatically because the left operand of + operator is
> uint64_t.
> but the result after integer promotion may be produce an error value for us
>
On Wed 05 Aug 2020 04:16:57 PM CEST, Kevin Wolf wrote:
>> nb_clusters is an int and there are more cases of
>>
>> nb_clusters << s->cluster_bits
>>
>> I can see at least these: handle_alloc(), qcow2_free_any_clusters(),
>> qcow2_alloc_cluster_abort().
>
> Actuallyx, handle_alloc() and
Am 05.08.2020 um 15:44 hat Alberto Garcia geschrieben:
> On Wed 05 Aug 2020 11:22:58 AM CEST, Tuguoyi wrote:
> > This patch fix it by casting @i to uint64_t before doing left shift
> > operation
>
> The patch seems fine and I also think that it's perhaps worth a test
> case (although it only
On 8/5/20 4:51 PM, Philippe Mathieu-Daudé wrote:
> On 8/5/20 12:08 PM, Denis V. Lunev wrote:
>> There are severe delays with IO requests processing if QEMU is running in
>> virtual machine or over software defined storage. Such delays potentially
>> results in unpredictable guest behavior. For
On 8/5/20 12:08 PM, Denis V. Lunev wrote:
> There are severe delays with IO requests processing if QEMU is running in
> virtual machine or over software defined storage. Such delays potentially
> results in unpredictable guest behavior. For example, guests over IDE or
> SATA drive could remount
On Wed 05 Aug 2020 03:44:08 PM CEST, Alberto Garcia wrote:
> On Wed 05 Aug 2020 11:22:58 AM CEST, Tuguoyi wrote:
>> This patch fix it by casting @i to uint64_t before doing left shift
>> operation
>
> The patch seems fine and I also think that it's perhaps worth a test
> case (although it only
On Wed 05 Aug 2020 11:22:58 AM CEST, Tuguoyi wrote:
> This patch fix it by casting @i to uint64_t before doing left shift
> operation
The patch seems fine and I also think that it's perhaps worth a test
case (although it only seems to happen with preallocation=falloc or full
so the test would
Am 05.08.2020 um 11:22 hat Tuguoyi geschrieben:
> When calculating the offset, the result of left shift operation will be
> promoted
> to type int64 automatically because the left operand of + operator is
> uint64_t.
> but the result after integer promotion may be produce an error value for us
On 8/5/20 4:22 AM, Tuguoyi wrote:
When calculating the offset, the result of left shift operation will be promoted
to type int64 automatically because the left operand of + operator is uint64_t.
but the result after integer promotion may be produce an error value for us and
trigger the following
On 05.08.2020 14:23, Vladimir Sementsov-Ogievskiy wrote:
30.07.2020 17:15, Andrey Shinkevich wrote:
The simple script creates a QCOW2 image and fills it with some data.
Two bitmaps are created as well. Then the script reads the image header
with extensions from the disk by running the script
Markus Armbruster writes:
> I let this series slide to get my Error API rework done, along with much
> else. My sincere apologies!
>
> Unsurprisingly, it needs a rebase now. I suggest to let me review it as
> is first.
I'm done with v6. Summary:
* A few trivial things to correct here and
30.07.2020 17:15, Andrey Shinkevich wrote:
The simple script creates a QCOW2 image and fills it with some data.
Two bitmaps are created as well. Then the script reads the image header
with extensions from the disk by running the script qcow2.py and dumps
the information to the output. Other
30.07.2020 15:02, Max Reitz wrote:
During migration, we release all bitmaps after storing them on disk, as
long as they are (1) stored on disk, (2) not read-only, and (3)
consistent.
(2) seems arbitrary, though. The reason we do not release them is
because we do not write them, as there is no
Kevin Wolf writes:
> Often, QMP command handlers are not only called to handle QMP commands,
> but also from a corresponding HMP command handler. In order to give them
> a consistent environment, optionally run HMP command handlers in a
> coroutine, too.
>
> The implementation is a lot simpler
On Wed, 5 Aug 2020 11:08:02 +0100
Daniel P. Berrangé wrote:
> On Wed, Aug 05, 2020 at 11:11:55AM +0200, Cornelia Huck wrote:
> > On Wed, 5 Aug 2020 10:05:40 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> > > > On 05/08/20
Markus Armbruster writes:
> Paolo Bonzini writes:
>
>> On 05/08/20 09:36, Markus Armbruster wrote:
>>> There's also the longer term pain of having to work around git-blame
>>> unable to see beyond the flag day.
>>
>> Do you really use "git blame" that much? "git log -S" does more or less
>>
Kevin Wolf writes:
> This moves the QMP dispatcher to a coroutine and runs all QMP command
> handlers that declare 'coroutine': true in coroutine context so they
> can avoid blocking the main loop while doing I/O or waiting for other
> events.
>
> For commands that are not declared safe to run
Right now BlockAcctStats is always reside on BlockBackend. This structure
is not used in any other place. Thus we are able to create a converter
from one pointer to another.
Signed-off-by: Denis V. Lunev
Reviewed-by: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC: Kevin Wolf
CC: Max
Latency threshold is set to 10 seconds following guest request timeout
on legacy storage controller.
Signed-off-by: Denis V. Lunev
CC: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC: Kevin Wolf
CC: Max Reitz
---
blockdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
There are severe delays with IO requests processing if QEMU is running in
virtual machine or over software defined storage. Such delays potentially
results in unpredictable guest behavior. For example, guests over IDE or
SATA drive could remount filesystem read-only if write is performed
longer
There are severe delays with IO requests processing if QEMU is running in
virtual machine or over software defined storage. Such delays potentially
results in unpredictable guest behavior. For example, guests over IDE or
SATA drive could remount filesystem read-only if write is performed
longer
aio_notify() does not set ctx->notified when called with
ctx->aio_notify_me disabled. Therefore aio_notify_me needs to be enabled
during polling.
This is suboptimal since expensive event_notifier_set(>notifier)
and event_notifier_test_and_clear(>notifier) calls are required
when
The event_notifier_*() prefix can be confused with the EventNotifier
APIs that are also called event_notifier_*().
Rename the functions to aio_context_notifier_*() to make it clear that
they relate to the AioContext::notifier field.
Signed-off-by: Stefan Hajnoczi
---
util/async.c | 8
Polling only monitors the ctx->notified field and does not need the
ctx->notifier EventNotifier to be signalled. Keep ctx->aio_notify_me
disabled while polling to avoid unnecessary EventNotifier syscalls.
This optimization improves virtio-blk 4KB random read performance by
18%. The following
v2:
* Added smp_mb() in aio_notify_accept() [Paolo]
* Added comments about memory barrier pairing [Paolo]
* Eliminated extra aio_compute_timeout() before calling ppoll()
This patch series eliminates ctx->notifier EventNotifier activity when
aio_poll() is in polling mode. There is no need to
When calculating the offset, the result of left shift operation will be promoted
to type int64 automatically because the left operand of + operator is uint64_t.
but the result after integer promotion may be produce an error value for us and
trigger the following asserting error.
For example,
On Wed, 5 Aug 2020 10:05:40 +0100
Daniel P. Berrangé wrote:
> On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> > On 05/08/20 10:39, Dr. David Alan Gilbert wrote:
> > >> Do you really use "git blame" that much? "git log -S" does more or less
> > >> the same function (in a
On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> On 05/08/20 10:39, Dr. David Alan Gilbert wrote:
> >> Do you really use "git blame" that much? "git log -S" does more or less
> >> the same function (in a different way) and is not affected as much by
> >> large code movement and
On Tue, Aug 04, 2020 at 06:53:09PM +0200, Paolo Bonzini wrote:
> On 04/08/20 12:29, Stefan Hajnoczi wrote:
> > On Tue, Aug 04, 2020 at 06:28:04AM +0100, Stefan Hajnoczi wrote:
> >> @@ -597,15 +574,38 @@ bool aio_poll(AioContext *ctx, bool blocking)
> >> * system call---a single round of
Paolo Bonzini writes:
> On 05/08/20 09:36, Markus Armbruster wrote:
>> There's also the longer term pain of having to work around git-blame
>> unable to see beyond the flag day.
>
> Do you really use "git blame" that much? "git log -S" does more or less
> the same function (in a different way)
On 05/08/20 10:39, Dr. David Alan Gilbert wrote:
>> Do you really use "git blame" that much? "git log -S" does more or less
>> the same function (in a different way) and is not affected as much by
>> large code movement and transformation patches.
>
> I use it a lot! Following stuff back to
On Wed, Aug 5, 2020 at 10:38 AM Vladimir Sementsov-Ogievskiy
wrote:
>
> 28.07.2020 19:05, Nir Soffer wrote:
> > On Tue, Jul 28, 2020 at 4:43 PM Vladimir Sementsov-Ogievskiy
> > wrote:
> >>
> >> 28.07.2020 00:58, Nir Soffer wrote:
> >>> Instead of duplicating the code to wait until the server is
On Wed, 5 Aug 2020 10:25:30 +0200
Paolo Bonzini wrote:
> On 05/08/20 09:36, Markus Armbruster wrote:
> > There's also the longer term pain of having to work around git-blame
> > unable to see beyond the flag day.
>
> Do you really use "git blame" that much? "git log -S" does more or less
>
Markus Armbruster writes:
> Paolo Bonzini writes:
[...]
>> That said, after a bit more research I'm skeptical about the possibility
>> of using an off-the-shelf parser because most of them either don't
>> support comments, or are based on YAJL which simply discards comments.
>>
>> Since '//'
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 05/08/20 09:36, Markus Armbruster wrote:
> > There's also the longer term pain of having to work around git-blame
> > unable to see beyond the flag day.
>
> Do you really use "git blame" that much? "git log -S" does more or less
> the same
Am 05.08.2020 um 09:28 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 04.08.2020 um 15:50 hat Markus Armbruster geschrieben:
> >> Kevin Wolf writes:
> >>
> >> > This way, a monitor command handler will still be able to access the
> >> > current monitor, but when it yields,
Am 05.08.2020 um 09:19 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 04.08.2020 um 14:46 hat Markus Armbruster geschrieben:
> >> > diff --git a/monitor/hmp.c b/monitor/hmp.c
> >> > index d598dd02bb..f609fcf75b 100644
> >> > --- a/monitor/hmp.c
> >> > +++ b/monitor/hmp.c
> >> >
On 05/08/20 09:36, Markus Armbruster wrote:
> There's also the longer term pain of having to work around git-blame
> unable to see beyond the flag day.
Do you really use "git blame" that much? "git log -S" does more or less
the same function (in a different way) and is not affected as much by
30.07.2020 15:02, Max Reitz wrote:
Hi,
When beginning migration, the qcow2 driver syncs all persistent bitmaps
to disk and then releases them. If the user decides to continue on the
source after migration, those bitmaps are re-loaded from the qcow2
image.
However, we only do this for bitmaps
29.07.2020 08:56, Andrey Shinkevich wrote:
On 28.07.2020 14:09, Vladimir Sementsov-Ogievskiy wrote:
17.07.2020 11:14, Andrey Shinkevich wrote:
As __dict__ is being extended with class members we do not want to
print, add the to_dict() method to classes that returns a dictionary
with desired
28.07.2020 19:05, Nir Soffer wrote:
On Tue, Jul 28, 2020 at 4:43 PM Vladimir Sementsov-Ogievskiy
wrote:
28.07.2020 00:58, Nir Soffer wrote:
Instead of duplicating the code to wait until the server is ready and
remember to terminate the server and wait for it, make it possible to
use like
John Snow writes:
> On 8/4/20 4:03 AM, Markus Armbruster wrote:
>> The pain of tweaking the parser is likely dwarved several times over by
>> the pain of the flag day.
>
> You mention this often; I wonder if I misunderstand the critique,
> because the pain of a "flag day" for a new file format
Kevin Wolf writes:
> Am 04.08.2020 um 15:50 hat Markus Armbruster geschrieben:
>> Kevin Wolf writes:
>>
>> > This way, a monitor command handler will still be able to access the
>> > current monitor, but when it yields, all other code code will correctly
>> > get NULL from monitor_cur().
>> >
Kevin Wolf writes:
> Am 04.08.2020 um 14:46 hat Markus Armbruster geschrieben:
>> > diff --git a/monitor/hmp.c b/monitor/hmp.c
>> > index d598dd02bb..f609fcf75b 100644
>> > --- a/monitor/hmp.c
>> > +++ b/monitor/hmp.c
>> > @@ -1301,11 +1301,11 @@ cleanup:
>> > static void monitor_read(void
62 matches
Mail list logo
