1. 31 Oct, 2014 7 commits
  2. 20 Oct, 2014 1 commit
    • Markus Armbruster's avatar
      hw: Convert from BlockDriverState to BlockBackend, mostly · 4be74634
      Markus Armbruster authored
      Device models should access their block backends only through the
      block-backend.h API.  Convert them, and drop direct includes of
      inappropriate headers.
      
      Just four uses of BlockDriverState are left:
      
      * The Xen paravirtual block device backend (xen_disk.c) opens images
        itself when set up via xenbus, bypassing blockdev.c.  I figure it
        should go through qmp_blockdev_add() instead.
      
      * Device model "usb-storage" prompts for keys.  No other device model
        does, and this one probably shouldn't do it, either.
      
      * ide_issue_trim_cb() uses bdrv_aio_discard() instead of
        blk_aio_discard() because it fishes its backend out of a BlockAIOCB,
        which has only the BlockDriverState.
      
      * PC87312State has an unused BlockDriverState[] member.
      
      The next two commits take care of the latter two.
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      4be74634
  3. 10 Oct, 2014 2 commits
  4. 26 Sep, 2014 8 commits
  5. 23 Sep, 2014 1 commit
  6. 16 Sep, 2014 1 commit
  7. 05 Sep, 2014 1 commit
    • Gerd Hoffmann's avatar
      console: stop using PixelFormat · 30f1e661
      Gerd Hoffmann authored
      With this patch the qemu console core stops using PixelFormat and pixman
      format codes side-by-side, pixman format code is the primary way to
      specify the DisplaySurface format:
      
       * DisplaySurface stops carrying a PixelFormat field.
       * qemu_create_displaysurface_from() expects a pixman format now.
      
      Functions to convert PixelFormat to pixman_format_code_t (and back)
      exist for those who still use PixelFormat.   As PixelFormat allows
      easy access to masks and shifts it will probably continue to exist.
      
      [ xenfb added by Benjamin Herrenschmidt ]
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      30f1e661
  8. 29 Aug, 2014 1 commit
  9. 12 Aug, 2014 2 commits
  10. 01 Jul, 2014 1 commit
    • Yang Zhiyong's avatar
      trace: add qemu_system_powerdown_request and qemu_system_shutdown_request trace events · bc78cff9
      Yang Zhiyong authored
      We have the experience that the guest doesn't stop successfully
      though it was instructed to shut down.
      
      The root cause may be not in QEMU mostly.  However, QEMU is often
      suspected at the beginning just because the issue occurred in
      virtualization environment.
      
      Therefore, we need to affirm that QEMU received the shutdown
      request and raised ACPI irq from "virsh shutdown" command,
      virt-manger or stopping QEMU process to the VM .
      So that we can affirm the problems was belonged to the Guset OS
      rather than the QEMU itself.
      
      When we stop guests by "virsh shutdown" command or virt-manger,
      or stopping QEMU process, qemu_system_powerdown_request() or
      qemu_system_shutdown_request() is called. Then the below functions
      in main_loop_should_exit() of Vl.c are called roughly in the
      following order.
      
      	if (qemu_powerdown_requested())
      		qemu_system_powerdown()
      			monitor_protocol_event(QEVENT_POWERDOWN, NULL)
      
      	OR
      
      	if(qemu_shutdown_requested()}
      		monitor_protocol_event(QEVENT_SHUTDOWN, NULL);
      
      The tracepoint of monitor_protocol_event() already exists, but no
      tracepoints are defined for qemu_system_powerdown_request() and
      qemu_system_shutdown_request(). So this patch adds two tracepoints for
      the two functions. We believe that it will become much easier to
      isolate the problem mentioned above by these tracepoints.
      Signed-off-by: default avatarYang Zhiyong <yangzy.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      bc78cff9
  11. 27 Jun, 2014 3 commits
    • Alexey Kardashevskiy's avatar
      spapr_pci: Use XICS interrupt allocator and do not cache interrupts in PHB · 9a321e92
      Alexey Kardashevskiy authored
      Currently SPAPR PHB keeps track of all allocated MSI (here and below
      MSI stands for both MSI and MSIX) interrupt because
      XICS used to be unable to reuse interrupts. This is a problem for
      dynamic MSI reconfiguration which happens when guest reloads a driver
      or performs PCI hotplug. Another problem is that the existing
      implementation can enable MSI on 32 devices maximum
      (SPAPR_MSIX_MAX_DEVS=32) and there is no good reason for that.
      
      This makes use of new XICS ability to reuse interrupts.
      
      This reorganizes MSI information storage in sPAPRPHBState. Instead of
      static array of 32 descriptors (one per a PCI function), this patch adds
      a GHashTable when @config_addr is a key and (first_irq, num) pair is
      a value. GHashTable can dynamically grow and shrink so the initial limit
      of 32 devices is gone.
      
      This changes migration stream as @msi_table was a static array while new
      @msi_devs is a dynamic hash table. This adds temporary array which is
      used for migration, it is populated in "spapr_pci"::pre_save() callback
      and expanded into the hash table in post_load() callback. Since
      the destination side does not know the number of MSI-enabled devices
      in advance and cannot pre-allocate the temporary array to receive
      migration state, this makes use of new VMSTATE_STRUCT_VARRAY_ALLOC macro
      which allocates the array automatically.
      
      This resets the MSI configuration space when interrupts are released by
      the ibm,change-msi RTAS call.
      
      This fixed traces to be more informative.
      
      This changes vmstate_spapr_pci_msi name from "...lsi" to "...msi" which
      was incorrect by accident. As the internal representation changed,
      thus bumps migration version number.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      [agraf: drop g_malloc_n usage]
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      9a321e92
    • Alexey Kardashevskiy's avatar
      xics: Implement xics_ics_free() · 51bba713
      Alexey Kardashevskiy authored
      This implements interrupt release function so IRQs can be returned back
      to the pool for reuse in cases such as PCI hot plug.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      51bba713
    • Alexey Kardashevskiy's avatar
      spapr: Move interrupt allocator to xics · bee763db
      Alexey Kardashevskiy authored
      The current allocator returns IRQ numbers from a pool and does not
      support IRQs reuse in any form as it did not keep track of what it
      previously returned, it only keeps the last returned IRQ. Some use
      cases such as PCI hot(un)plug may require IRQ release and reallocation.
      
      This moves an allocator from SPAPR to XICS.
      
      This switches IRQ users to use new API.
      
      This uses LSI/MSI flags to know if interrupt is allocated.
      
      The interrupt release function will be posted as a separate patch.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      bee763db
  12. 19 Jun, 2014 2 commits
  13. 16 Jun, 2014 4 commits
    • Alexey Kardashevskiy's avatar
      spapr_iommu: Enable multiple TCE requests · da95324e
      Alexey Kardashevskiy authored
      Currently only single TCE entry per request is supported (H_PUT_TCE).
      However PAPR+ specification allows multiple entry requests such as
      H_PUT_TCE_INDIRECT and H_STUFF_TCE. Having less transitions to the host
      kernel via ioctls, support of these calls can accelerate IOMMU operations.
      
      This implements H_STUFF_TCE and H_PUT_TCE_INDIRECT.
      
      This advertises "multi-tce" capability to the guest if the host kernel
      supports it (KVM_CAP_SPAPR_MULTITCE) or guest is running in TCG mode.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      da95324e
    • Alexey Kardashevskiy's avatar
      spapr: Implement processor compatibility in ibm, client-architecture-support · 3794d548
      Alexey Kardashevskiy authored
      Modern Linux kernels support last POWERPC CPUs so when a kernel boots,
      in most cases it can find a matching cpu_spec in the kernel's cpu_specs
      list. However if the kernel is quite old, it may be missing a definition
      of the actual CPU. To provide an ability for old kernels to work on modern
      hardware, a Processor Compatibility Mode has been introduced
      by the PowerISA specification.
      
      >From the hardware prospective, it is supported by the Processor
      Compatibility Register (PCR) which is defined in PowerISA. The register
      enables one of the compatibility modes (2.05/2.06/2.07).
      Since PCR is a hypervisor privileged register and cannot be
      directly accessed from the guest, the mode selection is done via
      ibm,client-architecture-support (CAS) RTAS call using which the guest
      specifies what "raw" and "architected" CPU versions it supports.
      QEMU works out the best match, changes a "cpu-version" property of
      every CPU and notifies the guest about the change by setting these
      properties in the buffer passed as a response on a custom H_CAS hypercall.
      
      This implements ibm,client-architecture-support parameters parsing
      (now only for PVRs) and cooks the device tree diff with new values for
      "cpu-version", "ibm,ppc-interrupt-server#s" and
      "ibm,ppc-interrupt-server#s" properties.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      3794d548
    • Alexey Kardashevskiy's avatar
      spapr: Add ibm, client-architecture-support call · 2a6593cb
      Alexey Kardashevskiy authored
      The PAPR+ specification defines a ibm,client-architecture-support (CAS)
      RTAS call which purpose is to provide a negotiation mechanism for
      the guest and the hypervisor to work out the best compatibility parameters.
      During the negotiation process, the guest provides an array of various
      options and capabilities which it supports, the hypervisor adjusts
      the device tree and (optionally) reboots the guest.
      
      At the moment the Linux guest calls CAS method at early boot so SLOF
      gets called. SLOF allocates a memory buffer for the device tree changes
      and calls a custom KVMPPC_H_CAS hypercall. QEMU parses the options,
      composes a diff for the device tree, copies it to the buffer provided
      by SLOF and returns to SLOF. SLOF updates the device tree and returns
      control to the guest kernel. Only then the Linux guest parses the device
      tree so it is possible to avoid unnecessary reboot in most cases.
      
      The device tree diff is a header with an update format version
      (defined as 1 in this patch) followed by a device tree with the properties
      which require update.
      
      If QEMU detects that it has to reboot the guest, it silently does so
      as the guest expects reboot to happen because this is usual pHyp firmware
      behavior.
      
      This defines custom KVMPPC_H_CAS hypercall. The current SLOF already
      has support for it.
      
      This implements stub which returns very basic tree (root node,
      no properties) to the guest.
      
      As the return buffer does not contain any change, no change in behavior is
      expected.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      2a6593cb
    • Alexey Kardashevskiy's avatar
      spapr: Add support for time base offset migration · 98a8b524
      Alexey Kardashevskiy authored
      This allows guests to have a different timebase origin from the host.
      
      This is needed for migration, where a guest can migrate from one host
      to another and the two hosts might have a different timebase origin.
      However, the timebase seen by the guest must not go backwards, and
      should go forwards only by a small amount corresponding to the time
      taken for the migration.
      
      This is only supported for recent POWER hardware which has the TBU40
      (timebase upper 40 bits) register. That includes POWER6, 7, 8 but not
      970.
      
      This adds kvm_access_one_reg() to access a special register which is not
      in env->spr. This requires kvm_set_one_reg/kvm_get_one_reg patch.
      
      The feature must be present in the host kernel.
      
      This bumps vmstate_spapr::version_id and enables new vmstate_ppc_timebase
      only for it. Since the vmstate_spapr::minimum_version_id remains
      unchanged, migration from older QEMU is supported but without
      vmstate_ppc_timebase.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      98a8b524
  14. 10 Jun, 2014 1 commit
  15. 02 Jun, 2014 2 commits
  16. 26 May, 2014 3 commits