1. 31 3月, 2012 1 次提交
  2. 12 1月, 2012 4 次提交
  3. 02 11月, 2011 1 次提交
  4. 24 10月, 2011 1 次提交
  5. 30 5月, 2011 1 次提交
    • M
      virtio: add api for delayed callbacks · 7ab358c2
      Michael S. Tsirkin 提交于
      Add an API that tells the other side that callbacks
      should be delayed until a lot of work has been done.
      Implement using the new event_idx feature.
      
      Note: it might seem advantageous to let the drivers
      ask for a callback after a specific capacity has
      been reached. However, as a single head can
      free many entries in the descriptor table,
      we don't really have a clue about capacity
      until get_buf is called. The API is the simplest
      to implement at the moment, we'll see what kind of
      hints drivers can pass when there's more than one
      user of the feature.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      7ab358c2
  6. 19 5月, 2010 3 次提交
  7. 13 3月, 2010 1 次提交
  8. 24 2月, 2010 1 次提交
  9. 03 2月, 2010 1 次提交
  10. 23 9月, 2009 1 次提交
  11. 12 6月, 2009 2 次提交
  12. 02 5月, 2008 1 次提交
    • R
      virtio: explicit advertisement of driver features · c45a6816
      Rusty Russell 提交于
      A recent proposed feature addition to the virtio block driver revealed
      some flaws in the API: in particular, we assume that feature
      negotiation is complete once a driver's probe function returns.
      
      There is nothing in the API to require this, however, and even I
      didn't notice when it was violated.
      
      So instead, we require the driver to specify what features it supports
      in a table, we can then move the feature negotiation into the virtio
      core.  The intersection of device and driver features are presented in
      a new 'features' bitmap in the struct virtio_device.
      
      Note that this highlights the difference between Linux unsigned-long
      bitmaps where each unsigned long is in native endian, and a
      straight-forward little-endian array of bytes.
      
      Drivers can still remove feature bits in their probe routine if they
      really have to.
      
      API changes:
      - dev->config->feature() no longer gets and acks a feature.
      - drivers should advertise their features in the 'feature_table' field
      - use virtio_has_feature() for extra sanity when checking feature bits
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      c45a6816
  13. 08 4月, 2008 1 次提交
    • R
      virtio: remove overzealous BUG_ON. · 2557a933
      Rusty Russell 提交于
      The 'disable_cb' callback is designed as an optimization to tell the host
      we don't need callbacks now.  As it is not reliable, the debug check is
      overzealous: it can happen on two CPUs at the same time.  Document this.
      
      Even if it were reliable, the virtio_net driver doesn't disable
      callbacks on transmit so the START_USE/END_USE debugging reentrance
      protection can be easily tripped even on UP.
      
      Thanks to Balaji Rao for the bug report and testing.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      CC: Balaji Rao <balajirrao@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2557a933
  14. 17 3月, 2008 1 次提交
    • C
      virtio: fix race in enable_cb · 4265f161
      Christian Borntraeger 提交于
      There is a race in virtio_net, dealing with disabling/enabling the callback.
      I saw the following oops:
      
      kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:218!
      illegal operation: 0001 [#1] SMP
      Modules linked in: sunrpc dm_mod
      CPU: 2 Not tainted 2.6.25-rc1zlive-host-10623-gd358142-dirty #99
      Process swapper (pid: 0, task: 000000000f85a610, ksp: 000000000f873c60)
      Krnl PSW : 0404300180000000 00000000002b81a6 (vring_disable_cb+0x16/0x20)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
      Krnl GPRS: 0000000000000001 0000000000000001 0000000010005800 0000000000000001
                 000000000f3a0900 000000000f85a610 0000000000000000 0000000000000000
                 0000000000000000 000000000f870000 0000000000000000 0000000000001237
                 000000000f3a0920 000000000010ff74 00000000002846f6 000000000fa0bcd8
      Krnl Code: 00000000002b819a: a7110001           tmll    %r1,1
                 00000000002b819e: a7840004           brc     8,2b81a6
                 00000000002b81a2: a7f40001           brc     15,2b81a4
                >00000000002b81a6: a51b0001           oill    %r1,1
                 00000000002b81aa: 40102000           sth     %r1,0(%r2)
                 00000000002b81ae: 07fe               bcr     15,%r14
                 00000000002b81b0: eb7ff0380024       stmg    %r7,%r15,56(%r15)
                 00000000002b81b6: a7f13e00           tmll    %r15,15872
      Call Trace:
      ([<000000000fa0bcd0>] 0xfa0bcd0)
       [<00000000002b8350>] vring_interrupt+0x5c/0x6c
       [<000000000010ab08>] do_extint+0xb8/0xf0
       [<0000000000110716>] ext_no_vtime+0x16/0x1a
       [<0000000000107e72>] cpu_idle+0x1c2/0x1e0
      
      The problem can be triggered with a high amount of host->guest traffic.
      I think its the following race:
      
      poll says netif_rx_complete
      poll calls enable_cb
      enable_cb opens the interrupt mask
      a new packet comes, an interrupt is triggered----\
      enable_cb sees that there is more work           |
      enable_cb disables the interrupt                 |
             .                                         V
             .                            interrupt is delivered
             .                            skb_recv_done does atomic napi test, ok
       some waiting                       disable_cb is called->check fails->bang!
             .
      poll would do napi check
      poll would do disable_cb
      
      The fix is to let enable_cb not disable the interrupt again, but expect the
      caller to do the cleanup if it returns false. In that case, the interrupt is
      only disabled, if the napi test_set_bit was successful.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (cleaned up doco)
      4265f161
  15. 04 2月, 2008 3 次提交
    • R
      virtio: reset function · 6e5aa7ef
      Rusty Russell 提交于
      A reset function solves three problems:
      
      1) It allows us to renegotiate features, eg. if we want to upgrade a
         guest driver without rebooting the guest.
      
      2) It gives us a clean way of shutting down virtqueues: after a reset,
         we know that the buffers won't be used by the host, and
      
      3) It helps the guest recover from messed-up drivers.
      
      So we remove the ->shutdown hook, and the only way we now remove
      feature bits is via reset.
      
      We leave it to the driver to do the reset before it deletes queues:
      the balloon driver, for example, needs to chat to the host in its
      remove function.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      6e5aa7ef
    • R
      virtio: configuration change callback · f957d1f0
      Rusty Russell 提交于
      Various drivers want to know when their configuration information
      changes: the balloon driver is the immediate user, but the network
      driver may one day have a "carrier" status as well.
      
      This introduces that callback (lguest doesn't use it yet).
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      f957d1f0
    • R
      virtio: explicit enable_cb/disable_cb rather than callback return. · 18445c4d
      Rusty Russell 提交于
      It seems that virtio_net wants to disable callbacks (interrupts) before
      calling netif_rx_schedule(), so we can't use the return value to do so.
      
      Rename "restart" to "cb_enable" and introduce "cb_disable" hook: callback
      now returns void, rather than a boolean.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      18445c4d
  16. 23 10月, 2007 1 次提交
    • R
      Virtio interface · ec3d41c4
      Rusty Russell 提交于
      This attempts to implement a "virtual I/O" layer which should allow
      common drivers to be efficiently used across most virtual I/O
      mechanisms.  It will no-doubt need further enhancement.
      
      The virtio drivers add buffers to virtio queues; as the buffers are consumed
      the driver "interrupt" callbacks are invoked.
      
      There is also a generic implementation of config space which drivers can query
      to get setup information from the host.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Dor Laor <dor.laor@qumranet.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      ec3d41c4