1. 22 5月, 2012 1 次提交
  2. 11 4月, 2012 1 次提交
    • D
      virtio-pci: change virtio balloon PCI class code · 2ba1d381
      David Gibson 提交于
      Currently the virtio balloon device, when using the virtio-pci interface
      advertises itself with PCI class code MEMORY_RAM.  This is wrong; the
      balloon is vaguely related to memory, but is nothing like a PCI memory
      device in the meaning of the class code, and this code is not required
      or suggested by the virtio PCI specification.
      
      Worse, this patch causes problems on the pseries machine, because the
      firmware, seeing this class code, advertises the device as memory in the
      device tree, and then a guest kernel bug causes it to see this "memory"
      before the real system memory, leading to a crash in early boot.
      
      This patch fixes the problem by removing the bogus PCI class code on the
      balloon device.  The backwards compatibility PC machines get new compat
      properties so that they don't change.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      2ba1d381
  3. 22 2月, 2012 1 次提交
  4. 15 2月, 2012 1 次提交
  5. 04 2月, 2012 2 次提交
    • A
      qdev: remove baked in notion of aliases (v2) · 6acbe4c6
      Anthony Liguori 提交于
      Limit them to the device_add functionality.  Device aliases were a hack based
      on the fact that virtio was modeled the wrong way.  The mechanism for aliasing
      is very limited in that only one alias can exist for any device.
      
      We have to support it for the purposes of compatibility but we only need to
      support it in device_add so restrict it to that piece of code.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      ---
      v1 -> v2
       - Use a table for aliases (Paolo)
      6acbe4c6
    • A
      qdev: register all types natively through QEMU Object Model · 39bffca2
      Anthony Liguori 提交于
      This was done in a mostly automated fashion.  I did it in three steps and then
      rebased it into a single step which avoids repeatedly touching every file in
      the tree.
      
      The first step was a sed-based addition of the parent type to the subclass
      registration functions.
      
      The second step was another sed-based removal of subclass registration functions
      while also adding virtual functions from the base class into a class_init
      function as appropriate.
      
      Finally, a python script was used to convert the DeviceInfo structures and
      qdev_register_subclass functions to TypeInfo structures, class_init functions,
      and type_register_static calls.
      
      We are almost fully converted to QOM after this commit.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      39bffca2
  6. 28 1月, 2012 2 次提交
  7. 21 1月, 2012 1 次提交
    • B
      virtio-pci: Fix endianness of virtio config · 82afa586
      Benjamin Herrenschmidt 提交于
      The virtio config area in PIO space is a bit special. The initial
      header is little endian but the rest (device specific) is guest
      native endian.
      
      The PIO accessors for PCI on machines that don't have native IO ports
      assume that all PIO is little endian, which works fine for everything
      except the above.
      
      A complicated way to fix it would be to split the BAR into two memory
      regions with different endianess settings, but this isn't practical
      to do, besides, the PIO code doesn't honor region endianness anyway
      (I have a patch for that too but it isn't necessary at this stage).
      
      So I decided to go for the quick fix instead which consists of
      reverting the swap in virtio-pci in selected places, hoping that when
      we eventually do a "v2" of the virtio protocols, we sort that out once
      and for all using a fixed endian setting for everything.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      [agraf: keep virtio in libhw and determine endianness through a
              helper function in exec.c]
      Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
      82afa586
  8. 14 1月, 2012 1 次提交
  9. 09 12月, 2011 1 次提交
  10. 05 12月, 2011 1 次提交
  11. 29 11月, 2011 1 次提交
  12. 02 11月, 2011 2 次提交
    • A
      Revert "virtio: Add PCI memory BAR in addition to PIO BAR" · b0eb8449
      Anthony Liguori 提交于
      This reverts commit 46d95bfe.
      b0eb8449
    • D
      virtio: Add PCI memory BAR in addition to PIO BAR · 46d95bfe
      David Gibson 提交于
      Currently, virtio devices are usually presented to the guest as an
      emulated PCI device, virtio_pci.  Although the actual IO operations
      are done through system memory, the configuration of the virtio device
      is done through the one PCI IO space BAR that virtio_pci presents.
      
      But PCI IO space (aka PIO) is deprecated for modern PCI devices, and
      on some systems with many PCI domains accessing PIO space can be
      problematic.  For example on the existing PowerVM implementation of
      the PAPR spec, PCI PIO access is not supported at all.  We're hoping
      that our KVM implementation will support PCI PIO (once we support PCI
      at all), but it will probably have some irritating limitations.
      
      This patch, therefore, extends the virtio_pci device to have a PCI
      memory space (MMIO) BAR as well as the IO BAR.  The MMIO BAR contains
      exactly the same registers, in exactly the same layout as the existing
      PIO BAR.
      
      Because the PIO BAR is still present, existing guest drivers should
      still work fine.  With this change in place, future guest drivers can
      check for an MMIO BAR and use that if present (falling back to PIO
      when possible to support older qemu versions).
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      46d95bfe
  13. 12 10月, 2011 1 次提交
  14. 08 8月, 2011 3 次提交
  15. 05 8月, 2011 2 次提交
  16. 28 7月, 2011 1 次提交
    • M
      virtio-pci: use generic logic for command access · 1129714f
      Michael S. Tsirkin 提交于
      In practice, guests don't generate config requests
      that cross a word boundary, so the logic to
      detect command word access is correct because
      PCI_COMMAND is 0x4. But depending on this is
      tricky, further, it will break with guests
      that do try to generate a misaligned access
      as we pass it to devices without splitting.
      
      Better to use the generic range_covers_byte for this.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      1129714f
  17. 05 7月, 2011 1 次提交
  18. 12 6月, 2011 2 次提交
  19. 02 6月, 2011 1 次提交
  20. 19 4月, 2011 1 次提交
  21. 04 4月, 2011 1 次提交
  22. 29 3月, 2011 1 次提交
    • M
      virtio-pci: fix bus master work around on load · 89c473fd
      Michael S. Tsirkin 提交于
      Commit c81131db
      detects old guests by comparing virtio and
      PCI status. It attempts to do this on load,
      as well, but load_config callback in a binding
      is invoked too early and so the virtio status
      isn't set yet.
      
      We could add yet another callback to the
      binding, to invoke after load, but it
      seems easier to reuse the existing vmstate
      callback.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Cc: Alexander Graf <agraf@suse.de>
      89c473fd
  23. 21 3月, 2011 2 次提交
  24. 02 2月, 2011 1 次提交
  25. 11 1月, 2011 1 次提交
  26. 10 1月, 2011 2 次提交
    • S
      virtio-pci: Use ioeventfd for virtqueue notify · 25db9ebe
      Stefan Hajnoczi 提交于
      Virtqueue notify is currently handled synchronously in userspace virtio.  This
      prevents the vcpu from executing guest code while hardware emulation code
      handles the notify.
      
      On systems that support KVM, the ioeventfd mechanism can be used to make
      virtqueue notify a lightweight exit by deferring hardware emulation to the
      iothread and allowing the VM to continue execution.  This model is similar to
      how vhost receives virtqueue notifies.
      
      The result of this change is improved performance for userspace virtio devices.
      Virtio-blk throughput increases especially for multithreaded scenarios and
      virtio-net transmit throughput increases substantially.
      
      Some virtio devices are known to have guest drivers which expect a notify to be
      processed synchronously and spin waiting for completion.
      For virtio-net, this also seems to interact with the guest stack in strange
      ways so that TCP throughput for small message sizes (~200bytes)
      is harmed. Only enable ioeventfd for virtio-blk for now.
      
      Care must be taken not to interfere with vhost-net, which uses host
      notifiers.  If the set_host_notifier() API is used by a device
      virtio-pci will disable virtio-ioeventfd and let the device deal with
      host notifiers as it wishes.
      
      Finally, there used to be a limit of 6 KVM io bus devices inside the
      kernel.  On such a kernel, don't use ioeventfd for virtqueue host
      notification since the limit is reached too easily.  This ensures that
      existing vhost-net setups (which always use ioeventfd) have ioeventfds
      available so they can continue to work.
      
      After migration and on VM change state (running/paused) virtio-ioeventfd
      will enable/disable itself.
      
       * VIRTIO_CONFIG_S_DRIVER_OK -> enable virtio-ioeventfd
       * !VIRTIO_CONFIG_S_DRIVER_OK -> disable virtio-ioeventfd
       * virtio_pci_set_host_notifier() -> disable virtio-ioeventfd
       * vm_change_state(running=0) -> disable virtio-ioeventfd
       * vm_change_state(running=1) -> enable virtio-ioeventfd
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      25db9ebe
    • S
      virtio-pci: Rename bugs field to flags · 3dbca8e6
      Stefan Hajnoczi 提交于
      The VirtIOPCIProxy bugs field is currently used to enable workarounds
      for older guests.  Rename it to flags so that other per-device behavior
      can be tracked.
      
      A later patch uses the flags field to remember whether ioeventfd should
      be used for virtqueue host notification.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      3dbca8e6
  27. 12 12月, 2010 1 次提交
  28. 21 11月, 2010 2 次提交
  29. 07 10月, 2010 1 次提交
  30. 08 9月, 2010 1 次提交
    • A
      virtio-net: Introduce a new bottom half packet TX · a697a334
      Alex Williamson 提交于
      Based on a patch from Mark McLoughlin, this patch introduces a new
      bottom half packet transmitter that avoids the latency imposed by
      the tx_timer approach.  Rather than scheduling a timer when a TX
      packet comes in, schedule a bottom half to be run from the iothread.
      The bottom half handler first attempts to flush the queue with
      notification disabled (this is where we could race with a guest
      without txburst).  If we flush a full burst, reschedule immediately.
      If we send short of a full burst, try to re-enable notification.
      To avoid a race with TXs that may have occurred, we must then
      flush again.  If we find some packets to send, the guest it probably
      active, so we can reschedule again.
      
      tx_timer and tx_bh are mutually exclusive, so we can re-use the
      tx_waiting flag to indicate one or the other needs to be setup.
      This allows us to seamlessly migrate between timer and bh TX
      handling.
      
      The bottom half handler becomes the new default and we add a new
      tx= option to virtio-net-pci.  Usage:
      
      -device virtio-net-pci,tx=timer # select timer mitigation vs "bh"
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      a697a334