1. 10 Apr, 2018 1 commit
  2. 09 Apr, 2018 3 commits
  3. 27 Mar, 2018 4 commits
  4. 26 Mar, 2018 2 commits
  5. 23 Mar, 2018 2 commits
    • Wei Huang's avatar
      mach-virt: Set VM's SMBIOS system version to mc->name · dfadc3bf
      Wei Huang authored
      Instead of using "1.0" as the system version of SMBIOS, we should use
      mc->name for mach-virt machine type to be consistent other architectures.
      With this patch, "dmidecode -t 1" (e.g., "-M virt-2.12,accel=kvm") will
      show:
      
          Handle 0x0100, DMI type 1, 27 bytes
          System Information
                  Manufacturer: QEMU
                  Product Name: KVM Virtual Machine
                  Version: virt-2.12
                  Serial Number: Not Specified
                  ...
      
      instead of:
      
          Handle 0x0100, DMI type 1, 27 bytes
          System Information
                  Manufacturer: QEMU
                  Product Name: KVM Virtual Machine
                  Version: 1.0
                  Serial Number: Not Specified
                  ...
      
      For backward compatibility, we allow older machine types to keep "1.0"
      as the default system version.
      Signed-off-by: 's avatarWei Huang <wei@redhat.com>
      Reviewed-by: 's avatarAndrew Jones <drjones@redhat.com>
      Message-id: 20180322212318.7182-1-wei@redhat.com
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      dfadc3bf
    • Trent Piepho's avatar
      i.MX: Support serial RS-232 break properly · 478a573a
      Trent Piepho authored
      Linux does not detect a break from this IMX serial driver as a magic
      sysrq.  Nor does it note a break in the port error counts.
      
      The former is because the Linux driver uses the BRCD bit in the USR2
      register to trigger the RS-232 break handler in the kernel, which is
      where sysrq hooks in.  The emulated UART was not setting this status
      bit.
      
      The latter is because the Linux driver expects, in addition to the BRK
      bit, that the ERR bit is set when a break is read in the FIFO.  A break
      should also count as a frame error, so add that bit too.
      
      Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
      Signed-off-by: 's avatarTrent Piepho <tpiepho@impinj.com>
      Message-id: 20180320013657.25038-1-tpiepho@impinj.com
      Reviewed-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      478a573a
  6. 20 Mar, 2018 5 commits
  7. 19 Mar, 2018 23 commits
    • Vladimir Sementsov-Ogievskiy's avatar
      block/accounting: introduce latency histogram · b741ae74
      Vladimir Sementsov-Ogievskiy authored
      Introduce latency histogram statics for block devices.
      For each accounted operation type, the latency region [0, +inf) is
      divided into subregions by several points. Then, calculate
      hits for each subregion.
      Signed-off-by: 's avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      Message-Id: <20180309165212.97144-2-vsementsov@virtuozzo.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Reviewed-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      b741ae74
    • Peter Xu's avatar
      qmp: support out-of-band (oob) execution · cf869d53
      Peter Xu authored
      Having "allow-oob":true for a command does not mean that this command
      will always be run in out-of-band mode.  The out-of-band quick path will
      only be executed if we specify the extra "run-oob" flag when sending the
      QMP request:
      
          { "execute":   "command-that-allows-oob",
            "arguments": { ... },
            "control":   { "run-oob": true } }
      
      The "control" key is introduced to store this extra flag.  "control"
      field is used to store arguments that are shared by all the commands,
      rather than command specific arguments.  Let "run-oob" be the first.
      
      Note that in the patch I exported qmp_dispatch_check_obj() to be used to
      check the request earlier, and at the same time allowed "id" field to be
      there since actually we always allow that.
      Reviewed-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: 's avatarPeter Xu <peterx@redhat.com>
      Message-Id: <20180309090006.10018-19-peterx@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      [eblake: rebase to qobject_to(), spelling fix]
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      cf869d53
    • Peter Xu's avatar
      qapi: introduce new cmd option "allow-oob" · 876c6751
      Peter Xu authored
      Here "oob" stands for "Out-Of-Band".  When "allow-oob" is set, it means
      the command allows out-of-band execution.
      
      The "oob" idea is proposed by Markus Armbruster in following thread:
      
        https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg02057.html
      
      This new "allow-oob" boolean will be exposed by "query-qmp-schema" as
      well for command entries, so that QMP clients can know which commands
      can be used in out-of-band calls. For example the command "migrate"
      originally looks like:
      
        {"name": "migrate", "ret-type": "17", "meta-type": "command",
         "arg-type": "86"}
      
      And it'll be changed into:
      
        {"name": "migrate", "ret-type": "17", "allow-oob": false,
         "meta-type": "command", "arg-type": "86"}
      
      This patch only provides the QMP interface level changes.  It does not
      contain the real out-of-band execution implementation yet.
      Suggested-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: 's avatarFam Zheng <famz@redhat.com>
      Signed-off-by: 's avatarPeter Xu <peterx@redhat.com>
      Message-Id: <20180309090006.10018-18-peterx@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      [eblake: rebase on introspection done by qlit]
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      876c6751
    • Peter Xu's avatar
      monitor: unify global init · 6adf08dd
      Peter Xu authored
      There are many places where the monitor initializes its globals:
      
      - monitor_init_qmp_commands() at the very beginning
      - single function to init monitor_lock
      - in the first entry of monitor_init() using "is_first_init"
      
      Unify them a bit.
      
      monitor_lock is not used before monitor_init() (as confirmed by code
      analysis and gdb watchpoints); so we are safe delaying what was a
      constructor-time initialization of the mutex into the later first call
      to monitor_init().
      Reviewed-by: 's avatarFam Zheng <famz@redhat.com>
      Reviewed-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarPeter Xu <peterx@redhat.com>
      Message-Id: <20180309090006.10018-8-peterx@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      6adf08dd
    • Peter Xu's avatar
      qobject: introduce qobject_get_try_str() · b26ae1cb
      Peter Xu authored
      A quick way to fetch string from qobject when it's a QString.
      Reviewed-by: 's avatarFam Zheng <famz@redhat.com>
      Reviewed-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: 's avatarPeter Xu <peterx@redhat.com>
      Message-Id: <20180309090006.10018-4-peterx@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      [eblake: rebase to qobject_to() macro]
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      b26ae1cb
    • Peter Xu's avatar
      qobject: introduce qstring_get_try_str() · 77593202
      Peter Xu authored
      The only difference from qstring_get_str() is that it allows the qstring
      to be NULL.  If so, NULL is returned.
      
      CC: Eric Blake <eblake@redhat.com>
      CC: Markus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarFam Zheng <famz@redhat.com>
      Reviewed-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarPeter Xu <peterx@redhat.com>
      Message-Id: <20180309090006.10018-3-peterx@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      77593202
    • Max Reitz's avatar
      qapi: Remove qobject_to_X() functions · cb51b976
      Max Reitz authored
      They are no longer needed now.
      Signed-off-by: 's avatarMax Reitz <mreitz@redhat.com>
      Reviewed-by: 's avatarAlberto Garcia <berto@igalia.com>
      Message-Id: <20180224154033.29559-5-mreitz@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      cb51b976
    • Max Reitz's avatar
      qapi: Add qobject_to() · 1a56b1e2
      Max Reitz authored
      This is a dynamic casting macro that, given a QObject type, returns an
      object as that type or NULL if the object is of a different type (or
      NULL itself).
      
      The macro uses lower-case letters because:
      1. There does not seem to be a hard rule on whether qemu macros have to
         be upper-cased,
      2. The current situation in qapi/qmp is inconsistent (compare e.g.
         QINCREF() vs. qdict_put()),
      3. qobject_to() will evaluate its @obj parameter only once, thus it is
         generally not important to the caller whether it is a macro or not,
      4. I prefer it aesthetically.
      
      The macro parameter order is chosen with typename first for
      consistency with other QAPI macros like QAPI_CLONE(), as well as
      for legibility (read it as "qobject to" type "applied to" obj).
      Signed-off-by: 's avatarMax Reitz <mreitz@redhat.com>
      Message-Id: <20180224154033.29559-3-mreitz@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Reviewed-by: 's avatarAlberto Garcia <berto@igalia.com>
      [eblake: swap parameter order to list type first, avoid clang ubsan
      warning on QOBJECT(NULL) and container_of(NULL,type,base)]
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      1a56b1e2
    • Peter Maydell's avatar
      hw/arm/bcm2836: Create proper bcm2837 device · 0fd74f03
      Peter Maydell authored
      The bcm2837 is pretty similar to the bcm2836, but it does have
      some differences. Notably, the MPIDR affinity aff1 values it
      sets for the CPUs are 0x0, rather than the 0xf that the bcm2836
      uses, and if this is wrong Linux will not boot.
      
      Rather than trying to have one device with properties that
      configure it differently for the two cases, create two
      separate QOM devices for the two SoCs. We use the same approach
      as hw/arm/aspeed_soc.c and share code and have a data table
      that might differ per-SoC. For the moment the two types don't
      actually have different behaviour.
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: 's avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Message-id: 20180313153458.26822-7-peter.maydell@linaro.org
      0fd74f03
    • Peter Maydell's avatar
      hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x · 926dcdf0
      Peter Maydell authored
      Our BCM2836 type is really a generic one that can be any of
      the bcm283x family. Rename it accordingly. We change only
      the names which are visible via the header file to the
      rest of the QEMU code, leaving private function names
      in bcm2836.c as they are.
      
      This is a preliminary to making bcm283x be an abstract
      parent class to specific types for the bcm2836 and bcm2837.
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: 's avatarAndrew Baumann <Andrew.Baumann@microsoft.com>
      Reviewed-by: 's avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Message-id: 20180313153458.26822-6-peter.maydell@linaro.org
      926dcdf0
    • Andrey Smirnov's avatar
      char: i.MX: Add support for "TX complete" interrupt · 46d3fb63
      Andrey Smirnov authored
      Add support for "TX complete"/TXDC interrupt generate by real HW since
      it is needed to support guests other than Linux.
      
      Based on the patch by Bill Paul as found here:
      https://bugs.launchpad.net/qemu/+bug/1753314
      
      Cc: qemu-devel@nongnu.org
      Cc: qemu-arm@nongnu.org
      Cc: Bill Paul <wpaul@windriver.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Signed-off-by: 's avatarBill Paul <wpaul@windriver.com>
      Signed-off-by: 's avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Message-id: 20180315191141.6789-2-andrew.smirnov@gmail.com
      Reviewed-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      46d3fb63
    • Guenter Roeck's avatar
      fsl-imx6: Swap Ethernet interrupt defines · 6461d7e2
      Guenter Roeck authored
      The sabrelite machine model used by qemu-system-arm is based on the
      Freescale/NXP i.MX6Q processor. This SoC has an on-board ethernet
      controller which is supported in QEMU using the imx_fec.c module
      (actually called imx.enet for this model.)
      
      The include/hw/arm/fsm-imx6.h file defines the interrupt vectors for the
      imx.enet device like this:
      
       #define FSL_IMX6_ENET_MAC_1588_IRQ 118
       #define FSL_IMX6_ENET_MAC_IRQ 119
      
      According to https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf,
      page 225, in Table 3-1. ARM Cortex A9 domain interrupt summary,
      interrupts are as follows.
      
      150 ENET MAC 0 IRQ
      151 ENET MAC 0 1588 Timer interrupt
      
      where
      
      150 - 32 == 118
      151 - 32 == 119
      
      In other words, the vector definitions in the fsl-imx6.h file are reversed.
      
      Fixing the interrupts alone causes problems with older Linux kernels:
      The Ethernet interface will fail to probe with Linux v4.9 and earlier.
      Linux v4.1 and earlier will crash due to a bug in Ethernet driver probe
      error handling. This is a Linux kernel problem, not a qemu problem:
      the Linux kernel only worked by accident since it requested both interrupts.
      
      For backward compatibility, generate the Ethernet interrupt on both interrupt
      lines. This was shown to work from all Linux kernel releases starting with
      v3.16.
      
      Link: https://bugs.launchpad.net/qemu/+bug/1753309Signed-off-by: 's avatarGuenter Roeck <linux@roeck-us.net>
      Message-id: 1520723090-22130-1-git-send-email-linux@roeck-us.net
      Reviewed-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      6461d7e2
    • Igor Mammedov's avatar
      Use cpu_create(type) instead of cpu_init(cpu_model) · 2278b939
      Igor Mammedov authored
      With all targets defining CPU_RESOLVING_TYPE, refactor
      cpu_parse_cpu_model(type, cpu_model) to parse_cpu_model(cpu_model)
      so that callers won't have to know internal resolving cpu
      type. Place it in exec.c so it could be called from both
      target independed vl.c and *-user/main.c.
      
      That allows us to stop abusing cpu type from
        MachineClass::default_cpu_type
      as resolver class in vl.c which were confusing part of
      cpu_parse_cpu_model().
      
      Also with new parse_cpu_model(), the last users of cpu_init()
      in null-machine.c and bsd/linux-user targets could be switched
      to cpu_create() API and cpu_init() API will be removed by
      follow up patch.
      
      With no longer users left remove MachineState::cpu_model field,
      new code should use MachineState::cpu_type instead and
      leave cpu_model parsing to generic code in vl.c.
      Signed-off-by: 's avatarIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <1518000027-274608-5-git-send-email-imammedo@redhat.com>
      [ehabkost: Fix bsd-user build error]
      Signed-off-by: 's avatarEduardo Habkost <ehabkost@redhat.com>
      2278b939
    • Max Reitz's avatar
      compiler: Add QEMU_BUILD_BUG_MSG() macro · 9139b567
      Max Reitz authored
      _Static_assert() allows us to specify messages, and that may come in
      handy.  Even without _Static_assert(), encouraging developers to put a
      helpful message next to the QEMU_BUILD_BUG_* may make debugging easier
      whenever it breaks.
      Signed-off-by: 's avatarMax Reitz <mreitz@redhat.com>
      Message-Id: <20180224154033.29559-2-mreitz@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Reviewed-by: 's avatarAlberto Garcia <berto@igalia.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      9139b567
    • Marc-André Lureau's avatar
      qlit: add qobject_from_qlit() · 3cf42b8b
      Marc-André Lureau authored
      Instantiate a QObject* from a literal QLitObject.
      
      LitObject only supports int64_t for now.  uint64_t and double aren't
      implemented.
      Signed-off-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180305172951.2150-4-marcandre.lureau@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      3cf42b8b
    • Marc-André Lureau's avatar
      qlit: use QType instead of int · 3d96ea44
      Marc-André Lureau authored
      Suggested-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Reviewed-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180305172951.2150-3-marcandre.lureau@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      3d96ea44
    • Liang Li's avatar
      block/mirror: change the semantic of 'force' of block-job-cancel · b76e4458
      Liang Li authored
      When doing drive mirror to a low speed shared storage, if there was heavy
      BLK IO write workload in VM after the 'ready' event, drive mirror block job
      can't be canceled immediately, it would keep running until the heavy BLK IO
      workload stopped in the VM.
      
      Libvirt depends on the current block-job-cancel semantics, which is that
      when used without a flag after the 'ready' event, the command blocks
      until data is in sync.  However, these semantics are awkward in other
      situations, for example, people may use drive mirror for realtime
      backups while still wanting to use block live migration.  Libvirt cannot
      start a block live migration while another drive mirror is in progress,
      but the user would rather abandon the backup attempt as broken and
      proceed with the live migration than be stuck waiting for the current
      drive mirror backup to finish.
      
      The drive-mirror command already includes a 'force' flag, which libvirt
      does not use, although it documented the flag as only being useful to
      quit a job which is paused.  However, since quitting a paused job has
      the same effect as abandoning a backup in a non-paused job (namely, the
      destination file is not in sync, and the command completes immediately),
      we can just improve the documentation to make the force flag obviously
      useful.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Jeff Cody <jcody@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: Max Reitz <mreitz@redhat.com>
      Cc: Eric Blake <eblake@redhat.com>
      Cc: John Snow <jsnow@redhat.com>
      Reported-by: 's avatarHuaitong Han <huanhuaitong@didichuxing.com>
      Signed-off-by: 's avatarHuaitong Han <huanhuaitong@didichuxing.com>
      Signed-off-by: 's avatarLiang Li <liliangleo@didichuxing.com>
      Signed-off-by: 's avatarJeff Cody <jcody@redhat.com>
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
      b76e4458
    • John Snow's avatar
      blockjobs: add block-job-finalize · 11b61fbc
      John Snow authored
      Instead of automatically transitioning from PENDING to CONCLUDED, gate
      the .prepare() and .commit() phases behind an explicit acknowledgement
      provided by the QMP monitor if auto_finalize = false has been requested.
      
      This allows us to perform graph changes in prepare and/or commit so that
      graph changes do not occur autonomously without knowledge of the
      controlling management layer.
      
      Transactions that have reached the "PENDING" state together can all be
      moved to invoke their finalization methods by issuing block_job_finalize
      to any one job in the transaction.
      
      Jobs in a transaction with mixed job->auto_finalize settings will all
      remain stuck in the "PENDING" state, as if the entire transaction was
      specified with auto_finalize = false. Jobs that specified
      auto_finalize = true, however, will still not emit the PENDING event.
      Signed-off-by: 's avatarJohn Snow <jsnow@redhat.com>
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
      11b61fbc
    • John Snow's avatar
      blockjobs: add PENDING status and event · 5f241594
      John Snow authored
      For jobs utilizing the new manual workflow, we intend to prohibit
      them from modifying the block graph until the management layer provides
      an explicit ACK via block-job-finalize to move the process forward.
      
      To distinguish this runstate from "ready" or "waiting," we add a new
      "pending" event and status.
      
      For now, the transition from PENDING to CONCLUDED/ABORTING is automatic,
      but a future commit will add the explicit block-job-finalize step.
      
      Transitions:
      Waiting -> Pending:   Normal transition.
      Pending -> Concluded: Normal transition.
      Pending -> Aborting:  Late transactional failures and cancellations.
      
      Removed Transitions:
      Waiting -> Concluded: Jobs must go to PENDING first.
      
      Verbs:
      Cancel: Can be applied to a pending job.
      
                   +---------+
                   |UNDEFINED|
                   +--+------+
                      |
                   +--v----+
         +---------+CREATED+-----------------+
         |         +--+----+                 |
         |            |                      |
         |         +--+----+     +------+    |
         +---------+RUNNING<----->PAUSED|    |
         |         +--+-+--+     +------+    |
         |            | |                    |
         |            | +------------------+ |
         |            |                    | |
         |         +--v--+       +-------+ | |
         +---------+READY<------->STANDBY| | |
         |         +--+--+       +-------+ | |
         |            |                    | |
         |         +--v----+               | |
         +---------+WAITING<---------------+ |
         |         +--+----+                 |
         |            |                      |
         |         +--v----+                 |
         +---------+PENDING|                 |
         |         +--+----+                 |
         |            |                      |
      +--v-----+   +--v------+               |
      |ABORTING+--->CONCLUDED|               |
      +--------+   +--+------+               |
                      |                      |
                   +--v-+                    |
                   |NULL<--------------------+
                   +----+
      Signed-off-by: 's avatarJohn Snow <jsnow@redhat.com>
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
      5f241594
    • John Snow's avatar
      blockjobs: add prepare callback · 2da4617a
      John Snow authored
      Some jobs upon finalization may need to perform some work that can
      still fail. If these jobs are part of a transaction, it's important
      that these callbacks fail the entire transaction.
      
      We allow for a new callback in addition to commit/abort/clean that
      allows us the opportunity to have fairly late-breaking failures
      in the transactional process.
      
      The expected flow is:
      
      - All jobs in a transaction converge to the PENDING state,
        added in a forthcoming commit.
      - Upon being finalized, either automatically or explicitly
        by the user, jobs prepare to complete.
      - If any job fails preparation, all jobs call .abort.
      - Otherwise, they succeed and call .commit.
      Signed-off-by: 's avatarJohn Snow <jsnow@redhat.com>
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
      2da4617a
    • John Snow's avatar
      blockjobs: add block_job_dismiss · 75f71059
      John Snow authored
      For jobs that have reached their CONCLUDED state, prior to having their
      last reference put down (meaning jobs that have completed successfully,
      unsuccessfully, or have been canceled), allow the user to dismiss the
      job's lingering status report via block-job-dismiss.
      
      This gives management APIs the chance to conclusively determine if a job
      failed or succeeded, even if the event broadcast was missed.
      
      Note: block_job_do_dismiss and block_job_decommission happen to do
      exactly the same thing, but they're called from different semantic
      contexts, so both aliases are kept to improve readability.
      
      Note 2: Don't worry about the 0x04 flag definition for AUTO_DISMISS, she
      has a friend coming in a future patch to fill the hole where 0x02 is.
      
      Verbs:
      Dismiss: operates on CONCLUDED jobs only.
      Signed-off-by: 's avatarJohn Snow <jsnow@redhat.com>
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
      75f71059
    • John Snow's avatar
      blockjobs: add block_job_verb permission table · 0ec4dfb8
      John Snow authored
      Which commands ("verbs") are appropriate for jobs in which state is
      also somewhat burdensome to keep track of.
      
      As of this commit, it looks rather useless, but begins to look more
      interesting the more states we add to the STM table.
      
      A recurring theme is that no verb will apply to an 'undefined' job.
      
      Further, it's not presently possible to restrict the "pause" or "resume"
      verbs any more than they are in this commit because of the asynchronous
      nature of how jobs enter the PAUSED state; justifications for some
      seemingly erroneous applications are given below.
      
      =====
      Verbs
      =====
      
      Cancel:    Any state except undefined.
      Pause:     Any state except undefined;
                 'created': Requests that the job pauses as it starts.
                 'running': Normal usage. (PAUSED)
                 'paused':  The job may be paused for internal reasons,
                            but the user may wish to force an indefinite
                            user-pause, so this is allowed.
                 'ready':   Normal usage. (STANDBY)
                 'standby': Same logic as above.
      Resume:    Any state except undefined;
                 'created': Will lift a user's pause-on-start request.
                 'running': Will lift a pause request before it takes effect.
                 'paused':  Normal usage.
                 'ready':   Will lift a pause request before it takes effect.
                 'standby': Normal usage.
      Set-speed: Any state except undefined, though ready may not be meaningful.
      Complete:  Only a 'ready' job may accept a complete request.
      
      =======
      Changes
      =======
      
      (1)
      
      To facilitate "nice" error checking, all five major block-job verb
      interfaces in blockjob.c now support an errp parameter:
      
      - block_job_user_cancel is added as a new interface.
      - block_job_user_pause gains an errp paramter
      - block_job_user_resume gains an errp parameter
      - block_job_set_speed already had an errp parameter.
      - block_job_complete already had an errp parameter.
      
      (2)
      
      block-job-pause and block-job-resume will no longer no-op when trying
      to pause an already paused job, or trying to resume a job that isn't
      paused. These functions will now report that they did not perform the
      action requested because it was not possible.
      
      iotests have been adjusted to address this new behavior.
      
      (3)
      
      block-job-complete doesn't worry about checking !block_job_started,
      because the permission table guards against this.
      
      (4)
      
      test-bdrv-drain's job implementation needs to announce that it is
      'ready' now, in order to be completed.
      Signed-off-by: 's avatarJohn Snow <jsnow@redhat.com>
      Reviewed-by: 's avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
      0ec4dfb8
    • John Snow's avatar
      blockjobs: add status enum · 58b295ba
      John Snow authored
      We're about to add several new states, and booleans are becoming
      unwieldly and difficult to reason about. It would help to have a
      more explicit bookkeeping of the state of blockjobs. To this end,
      add a new "status" field and add our existing states in a redundant
      manner alongside the bools they are replacing:
      
      UNDEFINED: Placeholder, default state. Not currently visible to QMP
                 unless changes occur in the future to allow creating jobs
                 without starting them via QMP.
      CREATED:   replaces !!job->co && paused && !busy
      RUNNING:   replaces effectively (!paused && busy)
      PAUSED:    Nearly redundant with info->paused, which shows pause_count.
                 This reports the actual status of the job, which almost always
                 matches the paused request status. It differs in that it is
                 strictly only true when the job has actually gone dormant.
      READY:     replaces job->ready.
      STANDBY:   Paused, but job->ready is true.
      
      New state additions in coming commits will not be quite so redundant:
      
      WAITING:   Waiting on transaction. This job has finished all the work
                 it can until the transaction converges, fails, or is canceled.
      PENDING:   Pending authorization from user. This job has finished all the
                 work it can until the job or transaction is finalized via
                 block_job_finalize. This implies the transaction has converged
                 and left the WAITING phase.
      ABORTING:  Job has encountered an error condition and is in the process
                 of aborting.
      CONCLUDED: Job has ceased all operations and has a return code available
                 for query and may be dismissed via block_job_dismiss.
      NULL:      Job has been dismissed and (should) be destroyed. Should never
                 be visible to QMP.
      
      Some of these states appear somewhat superfluous, but it helps define the
      expected flow of a job; so some of the states wind up being synchronous
      empty transitions. Importantly, jobs can be in only one of these states
      at any given time, which helps code and external users alike reason about
      the current condition of a job unambiguously.
      Signed-off-by: 's avatarJohn Snow <jsnow@redhat.com>
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
      58b295ba