Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 11 6月, 2015 2 次提交
  3. 01 6月, 2015 1 次提交
  5. 31 5月, 2015 1 次提交
  7. 28 4月, 2015 2 次提交
  9. 26 3月, 2015 1 次提交
  11. 25 3月, 2015 2 次提交
  13. 18 3月, 2015 2 次提交
  15. 12 3月, 2015 2 次提交
  17. 10 3月, 2015 7 次提交
    • E
      scsi-hd: fix property unset case · df1d4c34
      由 Ekaterina Tumanova 提交于 
      Commit c53659f0 ("BlockConf: Call backend functions to detect geometry
and blocksizes") causes a segmentation fault on the invalid
configuration of a scsi device without a drive.

Let's check for conf.blk before calling blkconf_blocksizes. The error
will be handled later on in scsi_realize anyway.
Reported-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NEkaterina Tumanova <tumanova@linux.vnet.ibm.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      df1d4c34
    • E
      BlockConf: Call backend functions to detect geometry and blocksizes · 0eb28a42
      由 Ekaterina Tumanova 提交于 
      geometry: hd_geometry_guess function autodetects the drive geometry.
This patch adds a block backend call, that probes the backing device
geometry. If the inner driver method is implemented and succeeds
(currently only for DASDs), the blkconf_geometry will pass-through
the backing device geometry. Otherwise will fallback to old logic.

blocksize: This patch initializes blocksize properties to 0.
In order to set the property a blkconf_blocksizes was introduced.
If user didn't set physical or logical blocksize, it will
retrieve its value from a driver (only succeeds for DASD), otherwise
it will set default 512 value.

The blkconf_blocksizes call was added to all users of BlkConf.
Signed-off-by: NEkaterina Tumanova <tumanova@linux.vnet.ibm.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1424087278-49393-6-git-send-email-tumanova@linux.vnet.ibm.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      0eb28a42
    • M
      scsi: Convert remaining PCI HBAs to realize() · ae071cc8
      由 Markus Armbruster 提交于 
      These are "am53c974", "dc390", "lsi53c895a", "lsi53c810", "megasas",
"megasas-gen2".
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-Id: <1425925048-15482-5-git-send-email-armbru@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      ae071cc8
    • M
      scsi: Improve error reporting for invalid drive property · 390e90a9
      由 Markus Armbruster 提交于 
      When setting "realized" fails, scsi_bus_legacy_add_drive() passes the
error to qerror_report_err(), then returns an unspecific "Setting
drive property failed" error, which is reported further up the call
chain.

Example:

    $ qemu-system-x86_64 -nodefaults -S -display none \
    > -drive if=scsi,id=foo,file=tmp.qcow2 -global isa-fdc.driveA=foo
    qemu-system-x86_64: -drive if=scsi,id=foo,file=tmp.qcow2: Property 'scsi-disk.drive' can't take value 'foo', it's in use
    qemu-system-x86_64: Setting drive property failed
    qemu-system-x86_64: Initialization of device lsi53c895a failed: Device initialization failed

Clean up the obvious way: simply return the original error to the
caller.  Gets rid of the second message in the above error cascade.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-Id: <1425925048-15482-4-git-send-email-armbru@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      390e90a9
    • M
      hw: Propagate errors through qdev_prop_set_drive() · 9b3d111a
      由 Markus Armbruster 提交于 
      Three kinds of callers:

1. On failure, report the error and abort

   Passing &error_abort does the job.  No functional change.

2. On failure, report the error and exit()

   This is qdev_prop_set_drive_nofail().  Error reporting moves from
   qdev_prop_set_drive() to its caller.  Because hiding away the error
   in the monitor right before exit() isn't helpful, replace
   qerror_report_err() by error_report_err().  Shouldn't make a
   difference, because qdev_prop_set_drive_nofail() should never be
   used in QMP context.

3. On failure, report the error and recover

   This is usb_msd_init() and scsi_bus_legacy_add_drive().  Error
   reporting and freeing the error object moves from
   qdev_prop_set_drive() to its callers.

   Because usb_msd_init() can't run in QMP context, replace
   qerror_report_err() by error_report_err() there.

   No functional change.

   scsi_bus_legacy_add_drive() calling qerror_report_err() is of
   course inappropriate, but this commit merely makes it more obvious.
   The next one will clean it up.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-Id: <1425925048-15482-3-git-send-email-armbru@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      9b3d111a
    • M
      scsi: Clean up duplicated error in legacy if=scsi code · fa617181
      由 Markus Armbruster 提交于 
      Commit a818a4b6 changed scsi_bus_legacy_handle_cmdline() to report
errors from scsi_bus_legacy_add_drive() with error_report() in
addition to returning them.  That's inappropriate.

Two kinds of callers:

1. realize methods (devices "esp", "virtio-scsi-device" and
   "spapr-vscsi")

   The error object gets passed up the call chain until it gets
   reported again and freed.

   Example:

   $ qemu-system-arm -M virt -S -display none \
   > -drive if=scsi,id=foo,bus=1,file=tmp.qcow2 \
   > -device nec-usb-xhci -device usb-storage,drive=foo \
   > -device virtio-scsi-pci
   qemu-system-arm: -drive if=scsi,id=foo,bus=1,file=tmp.qcow2: Property 'scsi-disk.drive' can't take value 'foo', it's in use
   qemu-system-arm: -drive if=scsi,id=foo,bus=1,file=tmp.qcow2: Setting drive property failed
   qemu-system-arm: -device virtio-scsi-pci: Setting drive property failed
   qemu-system-arm: -device virtio-scsi-pci: Device initialization failed
   qemu-system-arm: -device virtio-scsi-pci: Device 'virtio-scsi-pci' could not be initialized

   The second message in this error cascade comes from
   scsi_bus_legacy_handle_cmdline().  The error object then gets
   passed up to the qdev_init() called from
   virtio_scsi_pci_init_pci(), which reports it again.

2. init methods (devices "am53c974", "dc390", "lsi53c895a",
   "lsi53c810", "megasas", "megasas-gen2")

   init methods need to report their errors with qerror_report().
   These don't.  The inappropriate error_report() papers over the bug.

   error_report() isn't the same as qerror_report() in QMP context,
   but this can't actually happen: QMP can still only hot-plug, and
   callers call scsi_bus_legacy_handle_cmdline() only on cold-plug.
   Except for sysbus_esp_realize(), but that can't be hot-plugged at
   all, as far as I can tell.

Fix the init methods and drop the inappropriate error_report() in
scsi_bus_legacy_handle_cmdline().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-Id: <1425925048-15482-2-git-send-email-armbru@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fa617181
    • G
      vhost-scsi: Remove superfluous '\n' around error_report() · f6a16175
      由 Gonglei 提交于 
      Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      f6a16175
  19. 09 3月, 2015 1 次提交
  21. 02 3月, 2015 1 次提交
    • M
      virtio-scsi: Allocate op blocker reason before blocking · f6758f7d
      由 Max Reitz 提交于 
      s->blocker is really only used in hw/scsi/virtio-scsi.c; the only places
where it is used in hw/scsi/virtio-scsi-dataplane.c is when it is
allocated and when it is freed. That does not make a whole lot of sense
(and is actually wrong because this leads to s->blocker potentially
being NULL when blk_op_block_all() is called in virtio-scsi.c), so move
the allocation and destruction of s->blocker to the device realization
and unrealization in virtio-scsi.c, respectively.

Case in point:

$ echo -e 'eject drv\nquit' | \
    x86_64-softmmu/qemu-system-x86_64 \
        -monitor stdio -machine accel=qtest -display none \
        -object iothread,id=thr -device virtio-scsi-pci,iothread=thr \
        -drive if=none,file=test.qcow2,format=qcow2,id=drv \
        -device scsi-cd,drive=drv

Without this patch:

(qemu) eject drv
[1]    10102 done
       10103 segmentation fault (core dumped)

With this patch:

(qemu) eject drv
Device 'drv' is busy: block device is in use by data plane
(qemu) quit
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Message-Id: <1425057113-26940-1-git-send-email-mreitz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      f6758f7d
  23. 27 2月, 2015 2 次提交
    • F
      virtio-scsi-dataplane: Call blk_set_aio_context within BQL · 05430559
      由 Fam Zheng 提交于 
      It's not safe to call blk_set_aio_context from outside BQL because of
the bdrv_drain_all there. Let's put it in the hotplug callback which
will be called by qdev device realization for each scsi device attached
to the bus.
Signed-off-by: NFam Zheng <famz@redhat.com>
Message-Id: <1423969591-23646-3-git-send-email-famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      05430559
    • P
      scsi: give device a parent before setting properties · 22647504
      由 Paolo Bonzini 提交于 
      This mimics what is done in qdev_device_add, and lets the device be
freed in case something goes wrong.  Otherwise, object_unparent returns
immediately without freeing the device, which is on the other hand left
in the parent bus's list of children.

scsi_bus_legacy_handle_cmdline then returns an error, and the HBA is
destroyed as well with object_unparent.  But the lingering device that
was not removed in scsi_bus_legacy_add_drive cannot be removed now either,
and bus_unparent gets stuck in an infinite loop trying to empty the list
of children.

The right fix of course would be to assert in bus_add_child that the
device already has a bus, and remove the "safety net" that adds the
drive to the QOM tree in device_set_realized.  I am not yet sure whether
that would entail changing all callers to qdev_create (as well as
isa_create and usb_create and the corresponding _try_create versions).
Reported-by: NMarkus Armbruster <armbru@redhat.com>
Tested-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      22647504
  25. 26 2月, 2015 2 次提交
  27. 18 2月, 2015 2 次提交
    • M
      monitor: Clean up around monitor_handle_fd_param() · 1677f4c6
      由 Markus Armbruster 提交于 
      monitor_handle_fd_param() is a wrapper around
monitor_handle_fd_param2() that feeds errors to qerror_report_err()
instead of returning them.  qerror_report_err() is inappropriate in
many contexts.  monitor_handle_fd_param() looks simpler than
monitor_handle_fd_param2(), which tempts use.  Remove the temptation:
drop the wrapper and open-code the (trivial) error handling instead.

Replace the open-coded qerror_report_err() by error_report_err() in
places that already use error_report().  Turns out that's everywhere.

While there, rename monitor_handle_fd_param2() to monitor_fd_param().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      1677f4c6
    • M
      vhost-scsi: Improve error reporting for invalid vhostfd · 248337e1
      由 Markus Armbruster 提交于 
      We get two error messages: one from monitor_handle_fd_param2(), and
another one from vhost_scsi_realize().  The second one gets suppressed
in QMP context.

That's because monitor_handle_fd_param() calls qerror_report_err().
Calling qerror_report_err() is always inappropriate in realize
methods, because it doesn't return the Error object.  It either
reports the error to stderr or the human monitor, or it stores it in
the QMP monitor, where it makes the QMP command fail even when the
realize method ignores the error and succeeds.  Fortunately,
vhost_scsi_realize() doesn't do that.

Fix by switching to monitor_handle_fd_param2().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      248337e1
  29. 16 2月, 2015 1 次提交
  31. 12 2月, 2015 3 次提交
  33. 06 2月, 2015 1 次提交
    • A
      migration: Append JSON description of migration stream · 8118f095
      由 Alexander Graf 提交于 
      One of the annoyances of the current migration format is the fact that
it's not self-describing. In fact, it's not properly describing at all.
Some code randomly scattered throughout QEMU elaborates roughly how to
read and write a stream of bytes.

We discussed an idea during KVM Forum 2013 to add a JSON description of
the migration protocol itself to the migration stream. This patch
adds a section after the VM_END migration end marker that contains
description data on what the device sections of the stream are composed of.

This approach is backwards compatible with any QEMU version reading the
stream, because QEMU just stops reading after the VM_END marker and ignores
any data following it.

With an additional external program this allows us to decipher the
contents of any migration stream and hopefully make migration bugs easier
to track down.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
      8118f095
  35. 02 2月, 2015 1 次提交
  37. 27 1月, 2015 1 次提交
  39. 14 1月, 2015 2 次提交
  41. 15 12月, 2014 3 次提交