1. 15 10月, 2019 1 次提交
  2. 14 10月, 2019 1 次提交
  3. 07 10月, 2019 8 次提交
  4. 30 9月, 2019 3 次提交
  5. 27 9月, 2019 1 次提交
    • M
      qemu_monitor: s/size_t/ULL/ in qemuMonitorSave{Virtual,Physical}Memory · 9a293d33
      Michal Privoznik 提交于
      As it turns out, on my 32bit ARM machine size_t is not the same
      size as ULL. However, @length argument for both functions is type
      of size_t but it's treated as ULL - for instance when passed to
      qemuMonitorJSONMakeCommand(). The problem is that because of
      "U:size" the virJSONValueObjectAddVArgs() expects an ULL argument
      but on the stack there are size_t and char * arguments (which
      coincidentally add up to size of ULL). So the created command has
      only two arguments "val" and incorrect "size" and no "path" which
      is required.
      
      I've tried to find other occurrences of this pattern but at the
      rest of places where size_t is used it tracks size of an array so
      that's safe.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ACKed-by: NPeter Krempa <pkrempa@redhat.com>
      9a293d33
  6. 25 9月, 2019 4 次提交
  7. 20 9月, 2019 4 次提交
  8. 04 9月, 2019 1 次提交
  9. 29 8月, 2019 1 次提交
  10. 23 7月, 2019 1 次提交
  11. 18 7月, 2019 9 次提交
  12. 20 6月, 2019 5 次提交
  13. 12 6月, 2019 1 次提交
    • P
      qemu: Use proper block job name when reconnecting to VM · 56c6893f
      Peter Krempa 提交于
      The hash table returned by qemuMonitorGetAllBlockJobInfo is organized by
      the frontend name (which skipps the 'drive-' prefix). While our code
      properly matches the jobs to the disk, qemu needs the full job name
      including the 'drive-' prefix to be able to identify jobs.
      
      Fix this by adding an argument to qemuMonitorGetAllBlockJobInfo which
      does not modify the job name before filling the hash.
      
      This fixes a regression where users would not be able to cancel/pivot
      block jobs after restarting libvirtd while a blockjob is running.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      56c6893f