Version 2 of
http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg05640.html.
Changes are broken out per-patch; the cumulative changes are:
- more granular structure (several patches in place of 1),
- rename force_fdctrl parameter to create_fdctrl,
- drop the separate compat knob
The no_floppy = 1 machine class setting causes default_floppy in
main() to become zero. Consequently, default_drive() will not call
drive_add() and drive_new() for IF_FLOPPY, index=0, meaning that no
default floppy drive will be created for the virtual machine. In that
case, board code should also
On Thu, May 28, 2015 at 10:04:07PM +0200, Laszlo Ersek wrote:
Version 2 of
http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg05640.html.
Changes are broken out per-patch; the cumulative changes are:
- more granular structure (several patches in place of 1),
- rename force_fdctrl
On 05/28/15 23:08, Gabriel L. Somlo wrote:
On Thu, May 28, 2015 at 10:04:07PM +0200, Laszlo Ersek wrote:
Version 2 of
http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg05640.html.
Changes are broken out per-patch; the cumulative changes are:
- more granular structure (several
On 05/28/2015 06:21 AM, Markus Armbruster wrote:
Cc: Kevin Wolf kw...@redhat.com
Cc: qemu-block@nongnu.org
Signed-off-by: Markus Armbruster arm...@redhat.com
---
block/blkdebug.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
Reviewed-by: Eric Blake ebl...@redhat.com
* John Snow (js...@redhat.com) wrote:
On 05/21/2015 09:19 AM, Kevin Wolf wrote:
The floppy controller spec describes three different controller phases,
which are currently not explicitly modelled in our emulation. Instead,
each phase is represented by a combination of flags in
On 05/28/2015 09:23 AM, Max Reitz wrote:
Can we mark the parameter optional, and only provide it when it is
non-zero? That way, qemu-img (which cannot set an interval) will not
report it, and the only time it will appear is if it was set as part
of opening the block device under qemu.
That
On Thu 28 May 2015 06:44:55 PM CEST, Kevin Wolf wrote:
Yeah, I'm not sure such duplication helps. I'd still like it
reported somewhere, though, as it is nice to query that a requested
setting is actually working.
This isn't duplicated information. You can have ImageInfoSpecificQCow2
show
On Thu, May 28, 2015 at 11:50:28PM +0200, Laszlo Ersek wrote:
...
I have no idea how big of a deal this is (i.e. how wrong it is for
this stuff to still be showing up when no FDC is provisioned on the
guest).
The _STA method will return 0 if the FDEN field is zero.
In the
- Original Message -
Draining is not necessary, I/O can happen as soon as the
commit coroutine yields. Draining can be necessary before
reopening the file for read/write, or while modifying the
backing file chain, but that is done separately in
bdrv_reopen_multiple or bdrv_close;
- Original Message -
bdrv_close already does that, and in fact hmp_drive_del would need
another drain after the flush (which bdrv_close does). So remove
the duplication.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Fam Zheng f...@redhat.com
---
blockdev.c | 3
mirror_exit does the replacing, which requires source and target to be
in sync, unfortunately we can't guarantee that before we have a complete
block pause mechanism. So for non-dataplane block jobs, let's do the old
thing as pre commit 5a7e7a0ba (block: let mirror blockjob run in BDS
AioContext)
On 05/29/15 01:53, Gabriel L. Somlo wrote:
On Thu, May 28, 2015 at 11:50:28PM +0200, Laszlo Ersek wrote:
...
I have no idea how big of a deal this is (i.e. how wrong it is for
this stuff to still be showing up when no FDC is provisioned on the
guest).
The _STA method will return 0
On 28/05/2015 07:29, Fam Zheng wrote:
If guest discards a source cluster, mirroring with bdrv_aio_readv is overkill.
Some protocols do zero upon discard, where it's best to use
bdrv_aio_write_zeroes, otherwise, bdrv_aio_discard will be enough.
Signed-off-by: Fam Zheng f...@redhat.com
On 28/05/2015 07:29, Fam Zheng wrote:
This checks that the discard on mirror source that effectively zeroes
data is also reflected by the data of target.
Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: John Snow js...@redhat.com
---
tests/qemu-iotests/132 | 59
On 28/05/2015 07:29, Fam Zheng wrote:
Only poll the specific type of event we are interested in, to avoid
stealing events that should be consumed by someone else.
Suggested-by: John Snow js...@redhat.com
Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: John Snow js...@redhat.com
---
On 28/05/2015 07:29, Fam Zheng wrote:
Like bdrv_is_allocated_above, this function follows the backing chain until
seeing
BDRV_BLOCK_ALLOCATED. Base is not included.
Reimplement bdrv_is_allocated on top.
Reimplement bdrv_get_block_status on top.
Can be fixed by whoever commits this, so
On 28/05/2015 04:49, Fam Zheng wrote:
On a second thought, although in this series, we only need to modify
virtio-{scsi,blk}, Wen pointed out that mirror job also wants this during
completion (because bdrv_swap is in a BH after the job coroutine returns).
Mirror needs to pause/resume the
On Thu, 05/28 11:40, Kevin Wolf wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer users.
Sorry, I'm confused. Do you mean there is a way to implement blk_pause
completely in block layer,
On 28/05/2015 13:11, Fam Zheng wrote:
Whoever uses ioeventfd needs to implement pause/resume, yes---not just
dataplane, also regular virtio-blk/virtio-scsi.
However, everyone else should be okay, because the bottom half runs
immediately and the big QEMU lock is not released in the
On 28/05/2015 13:44, Fam Zheng wrote:
The reason for doing it in the block layer is that it's in one place and
we can be sure that it's applied. We can still in addition modify
specific users to avoid even trying to send requests, but I think it's
good to have the single place that
On 28/05/2015 12:46, Fam Zheng wrote:
Mirror needs to pause/resume the source. It doesn't need to handle
pause/resume of the target, does it?
So, in order for the solution to be general, and complete, this
nofitier list
approach relies on the listening devices to do the
On Thu, 05/28 13:24, Kevin Wolf wrote:
Am 28.05.2015 um 13:00 hat Paolo Bonzini geschrieben:
On 28/05/2015 12:55, Fam Zheng wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer
On 28/05/2015 12:55, Fam Zheng wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer users.
Sorry, I'm confused. Do you mean there is a way to implement blk_pause
completely in block
On 05/09/2015 01:21 AM, Kevin Wolf wrote:
Instead of letting every caller of bdrv_open() determine the right flags
for its child node manually and pass them to the function, pass the
parent node and the role of the newly opened child (like backing file,
protocol layer, etc.).
Signed-off-by:
Copying John Snow (FDC maintainer) and the qemu-block list.
Am 27.05.2015 um 23:06 hat Laszlo Ersek geschrieben:
It is Very annoying to carry forward an outdatEd coNtroller with a mOdern
Machine type.
Hence, let us not instantiate the FDC when all of the following apply:
- the machine type
Am 28.05.2015 um 02:59 hat Wen Congyang geschrieben:
On 05/27/2015 08:31 PM, Kevin Wolf wrote:
Am 21.05.2015 um 07:47 hat Wen Congyang geschrieben:
On 05/09/2015 01:21 AM, Kevin Wolf wrote:
For bs-file, using references to existing BDSes has been possible for a
while already. This patch
On 28/05/2015 13:24, Kevin Wolf wrote:
Am 28.05.2015 um 13:00 hat Paolo Bonzini geschrieben:
On 28/05/2015 12:55, Fam Zheng wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer users.
On Thu, 05/28 13:19, Paolo Bonzini wrote:
On 28/05/2015 13:16, Fam Zheng wrote:
On 28/05/2015 03:46, Fam Zheng wrote:
The main context uses iohandler and aio_dispatch, neither calls
aio_set_dispatching(). However, if we have [2], they can be changed to
aio_poll(), then would
Am 28.05.2015 um 04:49 hat Fam Zheng geschrieben:
On Wed, 05/27 12:43, Paolo Bonzini wrote:
On 27/05/2015 12:10, Kevin Wolf wrote:
Am 27.05.2015 um 11:50 hat Paolo Bonzini geschrieben:
On 27/05/2015 11:07, Kevin Wolf wrote:
This is the first part of what's troubling me with
On 28/05/2015 13:16, Fam Zheng wrote:
On 28/05/2015 03:46, Fam Zheng wrote:
The main context uses iohandler and aio_dispatch, neither calls
aio_set_dispatching(). However, if we have [2], they can be changed to
aio_poll(), then would this idea work?
I think it's a bad idea to
On Thu, 05/28 13:19, Paolo Bonzini wrote:
On 28/05/2015 13:11, Fam Zheng wrote:
Whoever uses ioeventfd needs to implement pause/resume, yes---not just
dataplane, also regular virtio-blk/virtio-scsi.
However, everyone else should be okay, because the bottom half runs
On Thu, 05/28 14:01, Paolo Bonzini wrote:
On 28/05/2015 13:49, Fam Zheng wrote:
On Thu, 05/28 13:19, Paolo Bonzini wrote:
On 28/05/2015 13:16, Fam Zheng wrote:
On 28/05/2015 03:46, Fam Zheng wrote:
The main context uses iohandler and aio_dispatch, neither calls
On 28/05/2015 13:49, Fam Zheng wrote:
On Thu, 05/28 13:19, Paolo Bonzini wrote:
On 28/05/2015 13:16, Fam Zheng wrote:
On 28/05/2015 03:46, Fam Zheng wrote:
The main context uses iohandler and aio_dispatch, neither calls
aio_set_dispatching(). However, if we have [2], they can be changed
Cc: Kevin Wolf kw...@redhat.com
Cc: qemu-block@nongnu.org
Signed-off-by: Markus Armbruster arm...@redhat.com
---
block/blkdebug.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index 50ef1fc..1e92607 100644
--- a/block/blkdebug.c
bdrv_close already does that, and in fact hmp_drive_del would need
another drain after the flush (which bdrv_close does). So remove
the duplication.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
blockdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
Draining is not necessary, I/O can happen as soon as the
commit coroutine yields. Draining can be necessary before
reopening the file for read/write, or while modifying the
backing file chain, but that is done separately in
bdrv_reopen_multiple or bdrv_close; this particular
bdrv_drain_all does
On 28/05/2015 14:26, Fam Zheng wrote:
Right, but the two sets of iohandlers are stored in different places, so
it's obvious that you don't execute all of them. On the other hand,
examining global state in aio_poll is really bad.
OK.
Would moving the ioeventfds to a new
On Thu 28 May 2015 04:17:09 PM CEST, Paolo Bonzini pbonz...@redhat.com wrote:
bdrv_close already does that, and in fact hmp_drive_del would need
another drain after the flush (which bdrv_close does). So remove
the duplication.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by:
On 27.05.2015 14:27, Eric Blake wrote:
On 05/27/2015 03:46 AM, Alberto Garcia wrote:
This adds a new 'cache-clean-interval' option that cleans all qcow2
cache entries that haven't been used in a certain interval, given in
seconds.
This allows setting a large L2 cache size so it can handle
On Thu 28 May 2015 05:14:12 PM CEST, Max Reitz wrote:
'compat': 'str',
'*lazy-refcounts': 'bool',
'*corrupt': 'bool',
- 'refcount-bits': 'int'
+ 'refcount-bits': 'int',
+ 'cache-clean-interval': 'int'
} }
I'm not too happy about making this
On 28.05.2015 17:13, Eric Blake wrote:
On 05/28/2015 08:56 AM, Max Reitz wrote:
On 27.05.2015 11:46, Alberto Garcia wrote:
This adds a new 'cache-clean-interval' option that cleans all qcow2
cache entries that haven't been used in a certain interval, given in
seconds.
This allows setting a
On 27.05.2015 11:46, Alberto Garcia wrote:
This adds a new 'cache-clean-interval' option that cleans all qcow2
cache entries that haven't been used in a certain interval, given in
seconds.
This allows setting a large L2 cache size so it can handle scenarios
with lots of I/O and at the same time
On 28.05.2015 17:02, Alberto Garcia wrote:
On Thu 28 May 2015 04:56:34 PM CEST, Max Reitz wrote:
'compat': 'str',
'*lazy-refcounts': 'bool',
'*corrupt': 'bool',
- 'refcount-bits': 'int'
+ 'refcount-bits': 'int',
+ 'cache-clean-interval': 'int'
} }
On 28.05.2015 17:04, Max Reitz wrote:
On 28.05.2015 17:02, Alberto Garcia wrote:
On Thu 28 May 2015 04:56:34 PM CEST, Max Reitz wrote:
'compat': 'str',
'*lazy-refcounts': 'bool',
'*corrupt': 'bool',
- 'refcount-bits': 'int'
+ 'refcount-bits': 'int',
+
On Thu 28 May 2015 04:56:34 PM CEST, Max Reitz wrote:
'compat': 'str',
'*lazy-refcounts': 'bool',
'*corrupt': 'bool',
- 'refcount-bits': 'int'
+ 'refcount-bits': 'int',
+ 'cache-clean-interval': 'int'
} }
I'm not too happy about making this part
On 05/28/2015 08:56 AM, Max Reitz wrote:
On 27.05.2015 11:46, Alberto Garcia wrote:
This adds a new 'cache-clean-interval' option that cleans all qcow2
cache entries that haven't been used in a certain interval, given in
seconds.
This allows setting a large L2 cache size so it can handle
Am 28.05.2015 um 17:37 hat Gerd Hoffmann geschrieben:
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/block/fdc.c| 2 +-
hw/i386/acpi-dsdt-isa.dsl | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
The commit message could be a bit longer, I don't think this change
On Thu, 05/28 13:47, Paolo Bonzini wrote:
On 28/05/2015 13:44, Fam Zheng wrote:
The reason for doing it in the block layer is that it's in one place and
we can be sure that it's applied. We can still in addition modify
specific users to avoid even trying to send requests, but I think
On Thu 28 May 2015 05:23:40 PM CEST, Max Reitz wrote:
Can we mark the parameter optional, and only provide it when it is
non-zero? That way, qemu-img (which cannot set an interval) will
not report it, and the only time it will appear is if it was set as
part of opening the block device under
On 28.05.2015 17:19, Alberto Garcia wrote:
On Thu 28 May 2015 05:14:12 PM CEST, Max Reitz wrote:
'compat': 'str',
'*lazy-refcounts': 'bool',
'*corrupt': 'bool',
- 'refcount-bits': 'int'
+ 'refcount-bits': 'int',
+ 'cache-clean-interval': 'int'
Am 28.05.2015 um 17:13 hat Eric Blake geschrieben:
On 05/28/2015 08:56 AM, Max Reitz wrote:
On 27.05.2015 11:46, Alberto Garcia wrote:
This adds a new 'cache-clean-interval' option that cleans all qcow2
cache entries that haven't been used in a certain interval, given in
seconds.
This
52 matches
Mail list logo
