Skip to content
Snippets Groups Projects
  1. Nov 23, 2010
  2. Jun 12, 2009
  3. Dec 29, 2008
    • Kay Sievers's avatar
      virtio: struct device - replace bus_id with dev_name(), dev_set_name() · 99e0b6c8
      Kay Sievers authored
      
      This patch is part of a larger patch series which will remove
      the "char bus_id[20]" name string from struct device. The device
      name is managed in the kobject anyway, and without any size
      limitation, and just needlessly copied into "struct device".
      
      To set and read the device name dev_name(dev) and dev_set_name(dev)
      must be used. If your code uses static kobjects, which it shouldn't
      do, "const char *init_name" can be used to statically provide the
      name the registered device should have. At registration time, the
      init_name field is cleared, to enforce the use of dev_name(dev) to
      access the device name at a later time.
      
      We need to get rid of all occurrences of bus_id in the entire tree
      to be able to enable the new interface. Please apply this patch,
      and possibly convert any remaining remaining occurrences of bus_id.
      
      We want to submit a patch to -next, which will remove bus_id from
      "struct device", to find the remaining pieces to convert, and finally
      switch over to the new api, which will remove the 20 bytes array
      and does no longer have a size limitation.
      
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      99e0b6c8
  4. Jul 24, 2008
  5. Jun 15, 2008
  6. May 29, 2008
    • Rusty Russell's avatar
      virtio: set device index in common code. · b769f579
      Rusty Russell authored
      
      Anthony Liguori points out that three different transports use the virtio code,
      but each one keeps its own counter to set the virtio_device's index field.  In
      theory (though not in current practice) this means that names could be
      duplicated, and that risk grows as more transports are created.
      
      So we move the selection of the unique virtio_device.index into the common code
      in virtio.c, which has the side-benefit of removing duplicate code.
      
      The only complexity is that lguest and S/390 use the index to uniquely identify
      the device in case of catastrophic failure before register_virtio_device() is
      called: now we use the offset within the descriptor page as a unique identifier
      for the printks.
      
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Lalancette <clalance@redhat.com>
      Cc: Anthony Liguori <anthony@codemonkey.ws>
      b769f579
    • Rusty Russell's avatar
      virtio: bus_id for devices should contain 'virtio' · 2ad3cfba
      Rusty Russell authored
      
      Chris Lalancette <clalance@redhat.com> points out that virtio.c sets all device
      names to '0', '1', etc, which looks silly in /proc/interrupts.  We change this
      from '%d' to 'virtio%d'.
      
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Lalancette <clalance@redhat.com>
      Cc: Anthony Liguori <anthony@codemonkey.ws>
      2ad3cfba
  7. May 02, 2008
    • Rusty Russell's avatar
      virtio: explicit advertisement of driver features · c45a6816
      Rusty Russell authored
      
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      c45a6816
  8. Feb 04, 2008
    • Rusty Russell's avatar
      virtio: Allow virtio to be modular and used by modules · c6fd4701
      Rusty Russell authored
      
      This is needed for the virtio PCI device to be compiled as a module.
      
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      c6fd4701
    • Rusty Russell's avatar
      virtio: reset function · 6e5aa7ef
      Rusty Russell authored
      
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      6e5aa7ef
    • Rusty Russell's avatar
      virtio: simplify config mechanism. · a586d4f6
      Rusty Russell authored
      
      Previously we used a type/len pair within the config space, but this
      seems overkill.  We now simply define a structure which represents the
      layout in the config space: the config space can now only be extended
      at the end.
      
      The main driver-visible changes:
      1) We indicate what fields are present with an explicit feature bit.
      2) Virtqueues are explicitly numbered, and not in the config space.
      
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      a586d4f6
  9. Nov 18, 2007
  10. Oct 22, 2007
    • Rusty Russell's avatar
      Module autoprobing support for virtio drivers. · b01d9f28
      Rusty Russell authored
      
      This adds the logic to convert the virtio ids into module aliases, and
      includes a modalias entry in sysfs and the env var to make probing work.
      
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      b01d9f28
    • Rusty Russell's avatar
      Virtio interface · ec3d41c4
      Rusty Russell authored
      
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Dor Laor <dor.laor@qumranet.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      ec3d41c4
Loading