1. 12 6月, 2009 2 次提交
  2. 19 4月, 2009 1 次提交
  3. 30 12月, 2008 1 次提交
  4. 25 8月, 2008 1 次提交
    • A
      virtio_balloon: fix towards_target when deflating balloon · 532a6086
      Anthony Liguori 提交于
      Both v and vb->num_pages are u32 and unsigned int respectively.  If v is less
      than vb->num_pages (and it is, when deflating the balloon), the result is a
      very large 32-bit number.  Since we're returning a s64, instead of getting the
      same negative number we desire, we get a very large positive number.
      
      This handles the case where v < vb->num_pages and ensures we get a small,
      negative, s64 as the result.
      
      Rusty: please push this for 2.6.27-rc4.  It's probably appropriate for the
      stable tree too as it will cause an unexpected OOM when ballooning.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (simplified)
      532a6086
  5. 02 5月, 2008 2 次提交
    • 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
    • R
      virtio: change config to guest endian. · 72e61eb4
      Rusty Russell 提交于
      A recent proposed feature addition to the virtio block driver revealed
      some flaws in the API, in particular how easy it is to break big
      endian machines.
      
      The virtio config space was originally chosen to be little-endian,
      because we thought the config might be part of the PCI config space
      for virtio_pci.  It's actually a separate mmio region, so that
      argument holds little water; as only x86 is currently using the virtio
      mechanism, we can change this (but must do so now, before the
      impending s390 merge).
      
      API changes:
      - __virtio_config_val() just becomes a striaght vdev->config_get() call.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      72e61eb4
  6. 17 3月, 2008 1 次提交
  7. 07 2月, 2008 2 次提交
  8. 04 2月, 2008 1 次提交
    • R
      virtio: balloon driver · 6b35e407
      Rusty Russell 提交于
      After discussions with Anthony Liguori, it seems that the virtio
      balloon can be made even simpler.  Here's my attempt.
      
      The device configuration tells the driver how much memory it should
      take from the guest (ie. balloon size).  The guest feeds the page
      numbers it has taken via one virtqueue.
      
      A second virtqueue feeds the page numbers the driver wants back: if
      the device has the VIRTIO_BALLOON_F_MUST_TELL_HOST bit, then this
      queue is compulsory, otherwise it's advisory (and the guest can simply
      fault the pages back in).
      
      This driver can be enhanced later to deflate the balloon via a
      shrinker, oom callback or we could even go for a complete set of
      in-guest regulators.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      6b35e407