Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 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
  3. 28 1月, 2012 2 次提交
  5. 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
  7. 14 1月, 2012 1 次提交
  9. 09 12月, 2011 1 次提交
  11. 05 12月, 2011 1 次提交
  13. 29 11月, 2011 1 次提交
  15. 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
  17. 12 10月, 2011 1 次提交
  19. 08 8月, 2011 3 次提交
  21. 05 8月, 2011 2 次提交
  23. 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
  25. 05 7月, 2011 1 次提交
  27. 12 6月, 2011 2 次提交
  29. 02 6月, 2011 1 次提交
  31. 19 4月, 2011 1 次提交
  33. 04 4月, 2011 1 次提交
  35. 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
  37. 21 3月, 2011 2 次提交
  39. 02 2月, 2011 1 次提交
  41. 11 1月, 2011 1 次提交
  43. 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
  45. 12 12月, 2010 1 次提交
  47. 21 11月, 2010 2 次提交
  49. 07 10月, 2010 1 次提交
  51. 08 9月, 2010 3 次提交
    • 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
    • A
      virtio-net: Limit number of packets sent per TX flush · e3f30488
      由 Alex Williamson 提交于 
      If virtio_net_flush_tx() is called with notification disabled, we can
race with the guest, processing packets at the same rate as they
get produced.  The trouble is that this means we have no guaranteed
exit condition from the function and can spend minutes in there.
Currently flush_tx is only called with notification on, which seems
to limit us to one pass through the queue per call.  An upcoming
patch changes this.

Also add an option to set this value on the command line as different
workloads may wish to use different values.  We can't necessarily
support any random value, so this is a developer option: x-txburst=
Usage:

-device virtio-net-pci,x-txburst=64 # 64 packets per tx flush

One pass through the queue (256) seems to be a good default value
for this, balancing latency with throughput.  We use a signed int
for x-txburst because 2^31 packets in a burst would take many, many
minutes to process and it allows us to easily return a negative
value value from virtio_net_flush_tx() to indicate a back-off
or error condition.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      e3f30488
    • A
      virtio-net: Make tx_timer timeout configurable · f0c07c7c
      由 Alex Williamson 提交于 
      Add an option to make the TX mitigation timer adjustable as a device
option.  The 150us hard coded default used currently is reasonable,
but may not be suitable for all workloads, this gives us a way to
adjust it using a single binary.  We can't support any random option
though, so use the "x-" prefix to indicate this is a developer
option.  Usage:

-device virtio-net-pci,x-txtimer=500000,... # .5ms timeout
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      f0c07c7c
  53. 24 8月, 2010 1 次提交
    • B
      Rearrange block headers · 2446333c
      由 Blue Swirl 提交于 
      Changing block.h or blockdev.h resulted in recompiling most objects.

Move DriveInfo typedef and BlockInterfaceType enum definitions
to qemu-common.h and rearrange blockdev.h use to decrease churn.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      2446333c
  55. 23 8月, 2010 1 次提交