On 21/03/2018 01:35, John Snow wrote:
>> The ATAPI_INT_REASON_IO interrupt is raised when I/O starts, but in the
>> AHCI case ide_set_irq was actually called at the end of a mutual recursion.
>> Move it early, with the side effect that ide_transfer_start becomes a tail
>> call in ide_atapi_cmd_repl
On 20/03/2018 23:11, John Snow wrote:
> Seems sane, with some lingering questions about what the PIO Setup FIS
> is supposed to do to begin with still remaining.
I agree here too. Smashing the ATA and controller in the same device
makes things tricky, so I tried to make these patches pure code mo
On 20/03/2018 22:46, John Snow wrote:
>> }
>> -if (s->bus->dma->ops->start_transfer) {
>> -s->bus->dma->ops->start_transfer(s->bus->dma);
>> +if (!s->bus->dma->ops->start_transfer) {
>> +s->end_transfer_func = end_transfer_func;
>> +return;
>> }
>> +s->
在 2018/3/21 11:12, QingFeng Hao 写道:
在 2018/3/20 22:31, Stefan Hajnoczi 写道:
On Tue, Mar 20, 2018 at 11:11:01AM +0100, Kevin Wolf wrote:
Am 19.03.2018 um 18:53 hat Christian Borntraeger geschrieben:
On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote:
On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Ha
在 2018/3/20 22:31, Stefan Hajnoczi 写道:
On Tue, Mar 20, 2018 at 11:11:01AM +0100, Kevin Wolf wrote:
Am 19.03.2018 um 18:53 hat Christian Borntraeger geschrieben:
On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote:
On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Hao wrote:
Test case 185 failed since
On 02/23/2018 10:26 AM, Paolo Bonzini wrote:
> The ATAPI_INT_REASON_IO interrupt is raised when I/O starts, but in the
> AHCI case ide_set_irq was actually called at the end of a mutual recursion.
> Move it early, with the side effect that ide_transfer_start becomes a tail
> call in ide_atapi_cmd
On 02/23/2018 10:26 AM, Paolo Bonzini wrote:
> There is code checking s->end_transfer_func and it was not taught
> about ide_transfer_cancel. We can just use ide_transfer_stop because
> s->end_transfer_func is only ever called in the DRQ phase: after
> ide_transfer_cancel, the value of s->end_tr
On 02/23/2018 10:26 AM, Paolo Bonzini wrote:
> The callback must be invoked once we get out of the DRQ phase; because
> all end_transfer_funcs end up invoking ide_transfer_stop, call it there.
> While at it, remove the "notify" argument from ide_transfer_halt; the
> code can simply be moved to id
On 02/23/2018 10:26 AM, Paolo Bonzini wrote:
> Split the PIO transfer across two callbacks, thus pushing the (possibly
> recursive) call to end_transfer_func up one level and out of the
> AHCI-specific code.
>
> Signed-off-by: Paolo Bonzini
> ---
> hw/ide/ahci.c | 7 ++-
> hw/i
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/213 | 349 +
tests/qemu-iotests/213.out | 121
tests/qemu-iotests/group | 1 +
3 files changed, 471 insertions(+)
create mode 100
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
It's unclear what the real maximum is, but we use an uint32_t to store
the log size in vhdx_co_create(), so we should check that the given
value fits in 32 bits.
Signed-off-by: Kevin Wolf
---
block/vhdx.c | 4
1 file changed, 4 insertions(+)
R
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
error_setg_errno() is meant for cases where we got an errno from the OS
that can add useful extra information to an error message. It's
pointless if we pass a constant errno, these cases should use plain
error_setg().
Well, it DOES let you get the libc-
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
Images with a non-power-of-two block size are invalid and cannot be
opened. Reject such block sizes when creating an image.
Signed-off-by: Kevin Wolf
---
block/vhdx.c | 4
1 file changed, 4 insertions(+)
Reviewed-by: Eric Blake
diff --git
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/212 | 326 +
tests/qemu-iotests/212.out | 111 +++
tests/qemu-iotests/group | 1 +
3 files changed, 438 insertions(+)
create mode 1007
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
It's unclear what the real maximum cluster size is for the Parallels
format, but let's at least make sure that we don't get integer
overflows in our .bdrv_co_create implementation.
Signed-off-by: Kevin Wolf
---
block/parallels.c | 5 +
1 file cha
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
This tests that the .bdrv_truncate implementation for luks doesn't crash
for invalid image sizes.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/210 | 37 +
1 file changed, 37 insertions(+)
Missing a change to
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
Commit e39e959e fixed an invalid assertion in the .bdrv_length
implementation, but left a similar assertion in place for
.bdrv_truncate. Instead of crashing when the user requests a too large
image size, fail gracefully.
A file size of exactly INT64_MAX
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
We want to test resizing even for luks. The only change that is needed
is to explicitly zero out new space for luks because it's undefined.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/025 | 9 -
1 file changed, 8 insertions(+), 1 deletio
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/211 | 256 +
tests/qemu-iotests/211.out | 98 +
tests/qemu-iotests/group | 1 +
3 files changed, 355 insertions(+)
create mode 10
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
Use qemu_uuid_unparse() instead of uuid_unparse() to make vdi.c compile
again when CONFIG_VDI_DEBUG is set. In order to prevent future bitrot,
replace '#ifdef CONFIG_VDI_DEBUG' by 'if (VDI_DEBUG)' so that the
compiler always sees the code.
Signed-off-by:
On 03/20/2018 12:36 PM, Kevin Wolf wrote:
What static=on really does is what we call metadata preallocation for
other block drivers. While we can still change the QMP interface, make
it more consistent by using 'preallocation' for VDI, too.
The x- naming of the command means we don't HAVE to ge
Peter Lieven wrote:
> the current implementation submits up to 512 I/O requests in parallel
> which is much to high especially for a background task.
> This patch adds a maximum limit of 16 I/O requests that can
> be submitted in parallel to avoid monopolizing the I/O device.
>
> Signed-off-by: Pe
Peter Lieven wrote:
> only read_done blocks are in the queued to be flushed to the migration
> stream. submitted blocks are still in flight.
>
> Signed-off-by: Peter Lieven
Reviewed-by: Juan Quintela
> ---
> migration/block.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff
On 03/20/2018 08:55 AM, Alberto Garcia wrote:
When we try to allocate new clusters we first look for available ones
starting from s->free_cluster_index and once we find them we increase
their reference counts. Before we get to call update_refcount() to do
this last step s->free_cluster_index is a
On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
>
> Very large projects often split in sub projects, maybe one of them
> describing the API. Then that API headers are similar to system headers
> and can be included using <>, although they still belong to the same
> larger project. Do
On Tue, Mar 20, 2018 at 05:34:01PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> > > Using <> for system include files and "" for local include files is a
> > > convention, an
It's unclear what the real maximum cluster size is for the Parallels
format, but let's at least make sure that we don't get integer
overflows in our .bdrv_co_create implementation.
Signed-off-by: Kevin Wolf
---
block/parallels.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/block/para
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/213 | 349 +
tests/qemu-iotests/213.out | 121
tests/qemu-iotests/group | 1 +
3 files changed, 471 insertions(+)
create mode 100755 tests/qemu-iotests/213
create mode 100644 te
Use qemu_uuid_unparse() instead of uuid_unparse() to make vdi.c compile
again when CONFIG_VDI_DEBUG is set. In order to prevent future bitrot,
replace '#ifdef CONFIG_VDI_DEBUG' by 'if (VDI_DEBUG)' so that the
compiler always sees the code.
Signed-off-by: Kevin Wolf
---
block/vdi.c | 22 +
This tests that the .bdrv_truncate implementation for luks doesn't crash
for invalid image sizes.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/210 | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/qemu-iotests/210 b/tests/qemu-iotests/210
index
error_setg_errno() is meant for cases where we got an errno from the OS
that can add useful extra information to an error message. It's
pointless if we pass a constant errno, these cases should use plain
error_setg().
Signed-off-by: Kevin Wolf
---
block/vhdx.c | 9 -
1 file changed, 4 in
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/211 | 256 +
tests/qemu-iotests/211.out | 98 +
tests/qemu-iotests/group | 1 +
3 files changed, 355 insertions(+)
create mode 100755 tests/qemu-iotests/211
create mode 100644 t
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/212 | 326 +
tests/qemu-iotests/212.out | 111 +++
tests/qemu-iotests/group | 1 +
3 files changed, 438 insertions(+)
create mode 100755 tests/qemu-iotests/212
create mode 100644 tes
Images with a non-power-of-two block size are invalid and cannot be
opened. Reject such block sizes when creating an image.
Signed-off-by: Kevin Wolf
---
block/vhdx.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/vhdx.c b/block/vhdx.c
index f1b97f4b49..ca211a3196 100644
--- a/blo
It's unclear what the real maximum is, but we use an uint32_t to store
the log size in vhdx_co_create(), so we should check that the given
value fits in 32 bits.
Signed-off-by: Kevin Wolf
---
block/vhdx.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/vhdx.c b/block/vhdx.c
index 0
Commit e39e959e fixed an invalid assertion in the .bdrv_length
implementation, but left a similar assertion in place for
.bdrv_truncate. Instead of crashing when the user requests a too large
image size, fail gracefully.
A file size of exactly INT64_MAX caused failure before, but is actually
legal
We want to test resizing even for luks. The only change that is needed
is to explicitly zero out new space for luks because it's undefined.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/025 | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/025 b/te
What static=on really does is what we call metadata preallocation for
other block drivers. While we can still change the QMP interface, make
it more consistent by using 'preallocation' for VDI, too.
This doesn't implement any new functionality, so the only supported
preallocation modes are 'off' a
This series adds qemu-iotests for a few more block drivers (yet more to
come in another series) and fixes a few things that previous review and
these tests brought up.
The only major design change is that I converted the vdi block driver
from a boolean 'static' create option to the standard 'preal
On 02/28/2018 12:05 PM, Max Reitz wrote:
This patch allows the user to specify whether to use active or only
background mode for mirror block jobs. Currently, this setting will
remain constant for the duration of the entire block job.
Signed-off-by: Max Reitz
---
qapi/block-core.json |
On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> > Using <> for system include files and "" for local include files is a
> > convention, and as far as I know most projects adhere to that
> > convention. So does QEMU
On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> Using <> for system include files and "" for local include files is a
> convention, and as far as I know most projects adhere to that
> convention. So does QEMU currently. Such conventions are not only
> important for humans, but also f
On Tue, Mar 20, 2018 at 02:54:37PM +0100, Max Reitz wrote:
> But I guess the main advantage with using this rule I see is that it's
> better for people reading the code. It's just nice to know whether a
> file belongs to qemu or not by just looking at the #include statement.
> (Note that this impl
On reopen with existing bitmaps, instead of loading bitmaps, lets
reopen them if needed. This also fixes bitmaps migration through
shared storage.
Consider the case. Persistent bitmaps are stored on bdrv_inactivate.
Then, on destination process_incoming_migration_bh() calls
bdrv_invalidate_cache_al
On reopen with existing bitmaps, instead of loading bitmaps, lets
reopen them if needed. This also fixes bitmaps migration through
shared storage.
Consider the case. Persistent bitmaps are stored on bdrv_inactivate.
Then, on destination process_incoming_migration_bh() calls
bdrv_invalidate_cache_al
Add version of qcow2_reopen_bitmaps_rw, which do the same work but
also return a hint about was header updated or not. This will be
used in the following fix for bitmaps reloading after migration.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Reviewed-by: Max Reitz
---
blo
Oh, sorry, just drop it.
(the only difference is commit message subject)
20.03.2018 20:05, Vladimir Sementsov-Ogievskiy wrote:
On reopen with existing bitmaps, instead of loading bitmaps, lets
reopen them if needed. This also fixes bitmaps migration through
shared storage.
Consider the case. Per
Hi all.
This fixes bitmaps migration through shared storage. Look at 02 for
details.
The bug introduced in 2.10 with the whole qcow2 bitmaps feature, so
qemu-stable in CC. However I doubt that someone really suffered from this.
Do we need dirty bitmaps at all in inactive case? - that was a quest
Shared migration for dirty bitmaps is fixed by previous patches,
so we can enable the test.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/169 | 8 +++-
tests/qemu-iotests/169.out | 4 ++--
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/tests/qemu-iote
On Tue, Mar 20, 2018 at 11:12:00AM -0500, Eric Blake wrote:
>
> Why can't we fix Makefile to include BOTH the build and the source
> directories (to pick up generated files first, and then version-controlled
> files), and possibly include logic to simplify to a single -I instead of two
> when doin
On Tue, Mar 20, 2018 at 11:12:00AM -0500, Eric Blake wrote:
> On 03/19/2018 08:54 PM, Michael S. Tsirkin wrote:
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
>
> [I'm replying without having read the rest of the thread, so bear with
Am 20.03.2018 um 02:54 schrieb Michael S. Tsirkin:
> QEMU coding style at the moment asks for all non-system
> include files to be used with #include "foo.h".
> However this rule actually does not make sense and
> creates issues for when the included file is generated.
>
> In C, include "file" mea
20.03.2018 16:44, Max Reitz wrote:
On 2018-03-19 10:02, Vladimir Sementsov-Ogievskiy wrote:
Consider migration with shared storage. Persistent bitmaps are stored
on bdrv_inactivate. Then, on destination
process_incoming_migration_bh() calls bdrv_invalidate_cache_all() which
leads to qcow2_load_a
20.03.2018 17:01, Max Reitz wrote:
On 2018-03-19 10:02, Vladimir Sementsov-Ogievskiy wrote:
Shared migration for dirty bitmaps is fixed by previous patches,
so we can enable the test.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/169 | 8 +++-
1 file changed, 3 inse
On 03/19/2018 08:54 PM, Michael S. Tsirkin wrote:
QEMU coding style at the moment asks for all non-system
include files to be used with #include "foo.h".
[I'm replying without having read the rest of the thread, so bear with
me if I repeat some of the other comments that have already been made
On Tue, Mar 20, 2018 at 04:04:21PM +0100, Kevin Wolf wrote:
> Hi,
>
> I just tried to add luks support to qemu-iotests 025, a basic resize
> test, which made me realise that luks doesn't read zeros in unwritten
> blocks (which makes the test fail).
>
> The reason for this is that we get zeros on
Hi,
I just tried to add luks support to qemu-iotests 025, a basic resize
test, which made me realise that luks doesn't read zeros in unwritten
blocks (which makes the test fail).
The reason for this is that we get zeros on the protocol layer (i.e. in
the encrpyted data as it is on the disk), but
On Tue, Mar 20, 2018 at 11:11:01AM +0100, Kevin Wolf wrote:
> Am 19.03.2018 um 18:53 hat Christian Borntraeger geschrieben:
> >
> >
> > On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote:
> > > On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Hao
> > > wrote:
> > >> Test case 185 failed since commit 4486e8
On Tue, Mar 20, 2018 at 03:50:02PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 01:41:17PM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > So for these, we should use "". None of these are generated file
On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > So for these, we should use "". None of these are generated files though.
> >
> > That leads to crazy inconsistent message for developers where 50% of QEMU
> > header files must use <> and the other 50% of header file
Hi,
> > So for these, we should use "". None of these are generated files though.
>
> That leads to crazy inconsistent message for developers where 50% of QEMU
> header files must use <> and the other 50% of header files must use "".
The rules are pretty simple though:
(1) Headers which a
On 2018-03-19 10:02, Vladimir Sementsov-Ogievskiy wrote:
> Add version of qcow2_reopen_bitmaps_rw, which do the same work but
> also return a hint about was header updated or not. This will be
> used in the following fix for bitmaps reloading after migration.
>
> Signed-off-by: Vladimir Sementsov-
On Tue, Mar 20, 2018 at 01:41:17PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > So for these, we should use "". None of these are generated files
> > > > though.
> > >
> > > That leads to crazy inconsistent message for d
On Tue, Mar 20, 2018 at 01:58:32PM +, Daniel P. Berrangé wrote:
> > That's the C language for you though. For better or worse, these are
> > the rules that K&R came up with.
>
> No one seriously tries to keep compliance with original K&R C these days,
> things have moved on massively since th
On 20.03.2018 14:32, Gerd Hoffmann wrote:
> Hi,
>
>>> So for these, we should use "". None of these are generated files though.
>>
>> That leads to crazy inconsistent message for developers where 50% of QEMU
>> header files must use <> and the other 50% of header files must use "".
>
> The rul
On 2018-03-19 10:02, Vladimir Sementsov-Ogievskiy wrote:
> Shared migration for dirty bitmaps is fixed by previous patches,
> so we can enable the test.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/169 | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
On 2018-03-20 14:41, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
So for these, we should use "". None of these are generated files though.
>>>
>>> That leads to crazy inconsistent message for developers where 50% of QEMU
>>> header fi
On Tue, Mar 20, 2018 at 01:10:41PM +, Stefan Hajnoczi wrote:
> On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote:
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
> > However this rule actually does not make sense a
On Tue, Mar 20, 2018 at 02:46:46PM +0100, Thomas Huth wrote:
> On 20.03.2018 14:32, Gerd Hoffmann wrote:
> > Hi,
> >
> >>> So for these, we should use "". None of these are generated files though.
> >>
> >> That leads to crazy inconsistent message for developers where 50% of QEMU
> >> header fi
When we try to allocate new clusters we first look for available ones
starting from s->free_cluster_index and once we find them we increase
their reference counts. Before we get to call update_refcount() to do
this last step s->free_cluster_index is already pointing to the next
cluster after the on
On 2018-03-19 10:02, Vladimir Sementsov-Ogievskiy wrote:
> Consider migration with shared storage. Persistent bitmaps are stored
> on bdrv_inactivate. Then, on destination
> process_incoming_migration_bh() calls bdrv_invalidate_cache_all() which
> leads to qcow2_load_autoloading_dirty_bitmaps() whi
On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote:
> QEMU coding style at the moment asks for all non-system
> include files to be used with #include "foo.h".
> However this rule actually does not make sense and
> creates issues for when the included file is generated.
>
> In C, i
On Tue, Mar 20, 2018 at 02:28:42PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote:
> > > > On Tue,
On Tue, Mar 20, 2018 at 12:39:00PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:28:42PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote:
> > > On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> > > > On Tue,
On Tue, Mar 20, 2018 at 10:01:24AM +, Peter Maydell wrote:
> On 20 March 2018 at 09:44, Daniel P. Berrangé wrote:
> > We can follow what autoconf does, and add a check to configure to see if
> > there are generated files left in the source dir, when configuring with
> > builddir != srcdir, and
On Tue, Mar 20, 2018 at 12:18:41PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote:
> > > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > > > Le 20/03/20
On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > > QEMU coding style at the moment asks for all non-system
> > > include files to be used with #include "f
On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote:
> QEMU coding style at the moment asks for all non-system
> include files to be used with #include "foo.h".
> However this rule actually does not make sense and
> creates issues for when the included file is generated.
>
> In C, i
On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
> > However this rule actually does not make sense and
> > creates is
On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > > > QEMU coding style at the mo
On Tue, Mar 20, 2018 at 10:27:19AM +, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 10:01:24AM +, Peter Maydell wrote:
> > On 20 March 2018 at 09:44, Daniel P. Berrangé wrote:
> > > We can follow what autoconf does, and add a check to configure to see if
> > > there are generated fil
Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> QEMU coding style at the moment asks for all non-system
> include files to be used with #include "foo.h".
> However this rule actually does not make sense and
> creates issues for when the included file is generated.
If you change that, we can
On 20 March 2018 at 09:44, Daniel P. Berrangé wrote:
> We can follow what autoconf does, and add a check to configure to see if
> there are generated files left in the source dir, when configuring with
> builddir != srcdir, and exit with error, telling user to clean their
> src dir first.
We alre
On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
> > However this rule actually does not make sense and
> > creates is
Am 08.03.2018 um 14:30 schrieb Peter Lieven:
Am 08.03.2018 um 13:50 schrieb Juan Quintela:
Peter Lieven wrote:
the current implementation submits up to 512 I/O requests in parallel
which is much to high especially for a background task.
This patch adds a maximum limit of 16 I/O requests that c
Am 12.03.2018 um 23:07 hat Fabiano Rosas geschrieben:
> Block drivers can be selected by either protocol syntax:
>
> :[:options]
>
> or explicitly:
>
> driver=[,option=...]
>
> For the protocol syntax to work, drivers should set the protocol_name
> field of the BlockDriver structure and pro
Am 19.03.2018 um 18:53 hat Christian Borntraeger geschrieben:
>
>
> On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote:
> > On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Hao
> > wrote:
> >> Test case 185 failed since commit 4486e89c219 --- "vl: introduce
> >> vm_shutdown()".
> >> It's because of the ne
87 matches
Mail list logo
