Currently, throttle timers won't make any progress when VCPU is not
running, which would stall the request queue in utils, qtest, vm
suspending, and live migration without special handling.
For example in bdrv_drain_all, all requests are resumed immediately
without taking throttling limit into account. This means whenever it is
called, IO throttling goes ineffective (examples: system reset,
migration and many block job operations.).
This might be some loophole that guest could exploit.
If we use the host clock, we can later just trust the nested poll when
waiting for requests.
Note that for qemu-iotests case 093, which sets up qtest when running
QEMU, we still use vm clock so the script can control the clock stepping
in order to be deterministic.
Signed-off-by: Fam Zheng <f...@redhat.com>
---
v2: Don't break qemu-iotests 093.
---
block.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 0fe97de..89a1d5b 100644
--- a/block.c
+++ b/block.c
@@ -30,6 +30,7 @@
#include "qapi/qmp/qjson.h"
#include "sysemu/block-backend.h"
#include "sysemu/sysemu.h"
+#include "sysemu/qtest.h"
#include "qemu/notify.h"
#include "block/coroutine.h"
#include "block/qapi.h"
@@ -181,10 +182,16 @@ static void bdrv_throttle_write_timer_cb(void *opaque)
/* should be called before bdrv_set_io_limits if a limit is set */
void bdrv_io_limits_enable(BlockDriverState *bs)
{
+ int clock_type = QEMU_CLOCK_REALTIME;
+
+ if (qtest_enabled()) {
+ /* For testing block IO throttling only */
+ clock_type = QEMU_CLOCK_VIRTUAL;
+ }
assert(!bs->io_limits_enabled);
throttle_init(&bs->throttle_state,
bdrv_get_aio_context(bs),
- QEMU_CLOCK_VIRTUAL,
+ clock_type,
bdrv_throttle_read_timer_cb,
bdrv_throttle_write_timer_cb,
bs);
--
1.9.3
