31 Dec, 2008

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
    lguest: struct device - replace bus_id with dev_name()
    lguest: move the initial guest page table creation code to the host
    kvm-s390: implement config_changed for virtio on s390
    virtio_console: support console resizing
    virtio: add PCI device release() function
    virtio_blk: fix type warning
    virtio: block: dynamic maximum segments
    virtio: set max_segment_size and max_sectors to infinite.
    virtio: avoid implicit use of Linux page size in balloon interface
    virtio: hand virtio ring alignment as argument to vring_new_virtqueue
    virtio: use KVM_S390_VIRTIO_RING_ALIGN instead of relying on pagesize
    virtio: use LGUEST_VRING_ALIGN instead of relying on pagesize
    virtio: Don't use PAGE_SIZE for vring alignment in virtio_pci.
    virtio: rename 'pagesize' arg to vring_init/vring_size
    virtio: Don't use PAGE_SIZE in virtio_pci.c
    virtio: struct device - replace bus_id with dev_name(), dev_set_name()
    virtio-pci queue allocation not page-aligned

    Linus Torvalds
     

30 Dec, 2008

3 commits

  • Fix parameter type warning:

    linux-next-20081126/drivers/block/virtio_blk.c:307: warning: large integer implicitly truncated to unsigned type

    Signed-off-by: Randy Dunlap
    cc: Rusty Russell
    Signed-off-by: Rusty Russell

    Randy Dunlap
     
  • Enhance the driver to handle whatever maximum segment number the host
    tells us to handle. Do to this, we need to allocate the scatterlist
    dynamically.

    We set max_phys_segments and max_hw_segments to the same value (1 if
    the host doesn't tell us, since that's safest and all known hosts do
    tell us).

    Note that kmalloc'ing the structure for large sg_elems might be
    problematic: the fix for this is sg_table, but that requires more
    work.

    Signed-off-by: Rusty Russell

    Rusty Russell
     
  • Setting max_segment_size allows more than 64k per sg element, unless
    the host specified a limit. Setting max_sectors indicates that our
    max_hw_segments is the only limit.

    Signed-off-by: Rusty Russell

    Rusty Russell
     

29 Dec, 2008

1 commit


21 Oct, 2008

3 commits

  • Signed-off-by: Al Viro

    Al Viro
     
  • To keep the size of changesets sane we split the switch by drivers;
    to keep the damn thing bisectable we do the following:
    1) rename the affected methods, add ones with correct
    prototypes, make (few) callers handle both. That's this changeset.
    2) for each driver convert to new methods. *ALL* drivers
    are converted in this series.
    3) kill the old (renamed) methods.

    Note that it _is_ a flagday; all in-tree drivers are converted and by the
    end of this series no trace of old methods remain. The only reason why
    we do that this way is to keep the damn thing bisectable and allow per-driver
    debugging if anything goes wrong.

    New methods:
    open(bdev, mode)
    release(disk, mode)
    ioctl(bdev, mode, cmd, arg) /* Called without BKL */
    compat_ioctl(bdev, mode, cmd, arg)
    locked_ioctl(bdev, mode, cmd, arg) /* Called with BKL, legacy */

    Signed-off-by: Al Viro

    Al Viro
     
  • Signed-off-by: Al Viro

    Al Viro
     

09 Oct, 2008

2 commits

  • This patch converts virtio_blk to use __blk_end_request() directly
    so that end_{queued|dequeued}_request() can be removed.
    Related 'uptodate' argument is converted to 'error'.

    Signed-off-by: Kiyoshi Ueda
    Signed-off-by: Jun'ichi Nomura
    Cc: Rusty Russell
    Signed-off-by: Jens Axboe

    Kiyoshi Ueda
     
  • struct request has an ioprio member but it is never updated because
    currently bios do not hold io context information. The implication of
    this is that virtio_blk ends up passing useless information to the
    backend driver.

    That said, some IO schedulers such as CFQ do store io context
    information in struct request, but use private members for that, which
    means that that information cannot be directly accessed in a IO
    scheduler-independent way.

    This patch adds a function to obtain the ioprio of a request. We should
    avoid accessing ioprio directly and use this function instead, so that
    its users do not have to care about future changes in block layer
    structures or what the currently active IO controller is.

    This patch does not introduce any functional changes but paves the way
    for future clean-ups and enhancements.

    Signed-off-by: Fernando Luis Vazquez Cao
    Acked-by: Rusty Russell
    Signed-off-by: Jens Axboe

    Fernando Luis Vázquez Cao
     

25 Jul, 2008

1 commit

  • Currently virtio_blk assumes a 512 byte hard sector size. This can cause
    trouble / performance issues if the backing has a different block size
    (like a file on an ext3 file system formatted with 4k block size or a dasd).

    Lets add a feature flag that tells the guest to use a different hard sector
    size than 512 byte.

    Signed-off-by: Christian Borntraeger
    Signed-off-by: Rusty Russell

    Christian Borntraeger
     

30 May, 2008

2 commits


02 May, 2008

5 commits

  • Rather than faking up some geometry, allow the backend to push the disk
    geometry via virtio pci config option. Keep the old geo code around for
    compatibility.

    Signed-off-by: Ryan Harper
    Reviewed-by: Anthony Liguori
    Signed-off-by: Rusty Russell (modified to single struct)

    Ryan Harper
     
  • 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: Rusty Russell

    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: Rusty Russell

    Rusty Russell
     
  • Do not unregister the major at device remove, since there might be
    another device instances around.

    (qemu) pci_del 0 11
    (qemu) ACPI: PCI interrupt for device 0000:00:0b.0 disabled
    (qemu) pci_del 0 10
    (qemu) ------------[ cut here ]------------
    WARNING: at block/genhd.c:126 unregister_blkdev+0x74/0x9e()
    ACPI: PCI interrupt for device 0000:00:0a.0 disabled

    Signed-off-by: Marcelo Tosatti
    Signed-off-by: Rusty Russell

    Marcelo Tosatti
     
  • Ron Minnich points out that a struct containing a char is not always
    sizeof(char); simplest to remove the structure to avoid confusion.

    Cc: "ron minnich"

    Signed-off-by: Rusty Russell

    Rusty Russell
     

17 Mar, 2008

1 commit


04 Feb, 2008

6 commits

  • Am Freitag, 1. Februar 2008 schrieb Christian Borntraeger:
    > Right. I will fix that with an additional patch.

    This patch goes on top of the minor number patch. Please let me know if
    you want a merged patch:

    Currently virtio_blk creates the disk name combinging "vd" with 'a'++.
    This will give strange names after vdz. I have implemented names up to
    vdzzz - inspired by the sd.c code. That should be sufficient for now.

    There is one driver in the kernel (driver/s390/block/dasd_genhd.c) that
    implements names from dasda-dasdzzzz allowing even more disks. Maybe
    a janitor can come up with a common implementation usable for all kind
    of block device drivers.

    I have tested this patch with 100 disks - seems to work.

    Signed-off-by: Christian Borntraeger
    Signed-off-by: Rusty Russell

    Christian Borntraeger
     
  • Rusty,

    currently virtio_blk uses one major number per device. While this works
    quite well on most systems it is wasteful and will exhaust major numbers
    on larger installations.

    This patch allocates a major number on init and will use 16 minor numbers
    for each disk. That will allow ~64k virtio_blk disks.

    Signed-off-by: Christian Borntraeger
    Signed-off-by: Rusty Russell

    Christian Borntraeger
     
  • Rusty,

    I currently try to make my guest boot from an virtio root device
    without having an external kernel. Some of the tools that I tried
    expect HDIO_GETGEO to work. The most interesting value is likely
    the geo.start value to get the offset of a partition. This value
    is filled by block/ioctl.c if fops->getgeo is set. This patch also
    fills in some standard values for heads, sectors and cylinders.

    Makes sense?

    Signed-off-by: Christian Borntraeger
    Signed-off-by: Rusty Russell

    Christian Borntraeger
     
  • 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: Rusty Russell

    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: Rusty Russell

    Rusty Russell
     
  • 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: Rusty Russell

    Rusty Russell
     

19 Nov, 2007

1 commit

  • The virtio code never hooked through the ->remove callback. Although
    noone supports device removal at the moment, this code is already
    needed for module unloading.

    This of course also revealed bugs in virtio_blk, virtio_net and lguest
    unloading paths.

    Signed-off-by: Rusty Russell

    Rusty Russell
     

24 Oct, 2007

1 commit


23 Oct, 2007

1 commit

  • The block driver uses scatter-gather lists with sg[0] being the
    request information (struct virtio_blk_outhdr) with the type, sector
    and inbuf id. The next N sg entries are the bio itself, then the last
    sg is the status byte. Whether the N entries are in or out depends on
    whether it's a read or a write.

    We accept the normal (SCSI) ioctls: they get handed through to the other
    side which can then handle it or reply that it's unsupported. It's
    not clear that this actually works in general, since I don't know
    if blk_pc_request() requests have an accurate rq_data_dir().

    Although we try to reply -ENOTTY on unsupported commands, ioctl(fd,
    CDROMEJECT) returns success to userspace. This needs a separate
    patch.

    Signed-off-by: Rusty Russell
    Cc: Jens Axboe

    Rusty Russell