lkml.org 
[lkml]   [2009]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCHv4] uio: add generic driver for PCI 2.3 devices
    Date
    On Thursday 16 July 2009 20:31:01 Michael S. Tsirkin wrote:
    > On Wed, Jul 15, 2009 at 03:08:29PM -0700, Greg KH wrote:
    > > On Wed, Jul 15, 2009 at 11:13:40PM +0300, Michael S. Tsirkin wrote:
    > > > This adds a generic uio driver that can bind to any PCI device. First
    > > > user will be virtualization where a qemu userspace process needs to
    > > > give guest OS access to the device.
    > > >
    > > > Interrupts are handled using the Interrupt Disable bit in the PCI
    > > > command register and Interrupt Status bit in the PCI status register.
    > > > All devices compliant to PCI 2.3 (circa 2002) and all compliant PCI
    > > > Express devices should support these bits. Driver detects this
    > > > support, and won't bind to devices which do not support the Interrupt
    > > > Disable Bit in the command register.
    > > >
    > > > It's expected that more features of interest to virtualization will be
    > > > added to this driver in the future. Possibilities are: mmap for device
    > > > resources, MSI/MSI-X, eventfd (to interface with kvm), iommu.
    > > >
    > > > Acked-by: Chris Wright <chrisw@redhat.com>
    > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    > > > ---
    > > >
    > > > Hans, Greg, please review and consider for upstream.
    > > >
    > > > This is intended to solve the problem in virtualization that shared
    > > > interrupts do not work with assigned devices. Earlier versions of this
    > > > patch have circulated on kvm@vger.
    > >
    > > How does this play with the pci-stub driver that I thought was written
    > > to solve this very problem?
    >
    > AFAIK the problem pci stub was written to solve is simply to bind to a
    > device. You then have to use another kernel module which looks the
    > device up with something like pci_get_bus_and_slot to do anything
    > useful. In particular, for non-shared interrupts, we can disable the
    > interrupt in the apic. But this does not work well for shared
    > interrupts. Thus this work.
    >
    > The uio driver will be used in virtualization scenarious, a couple
    > of possible ones that have been mentioned on the kvm list are:
    > - device assignment (guest access to device) for simple devices with
    > shared interrupts: emulating PCI is tricky enough to better be done in
    > userspace. shared interrupt support is important as it happens
    > with real devices

    One comments for shared interrupt: if you means guest device shares interrupt
    with device in other domain(that means guest or host), it's still a security
    hole, and our position seems still won't-do it. Could you explain how the
    situation change with this patch? I am not sure if I understand your meaning
    completely...

    Thanks.

    --
    regards
    Yang, Sheng

    > - simple communication between guest and host:
    > we create a virtual device in host, and userspace
    > driver in guest gets events and passes them on
    > to e.g. dbus. shared interrupt support is important
    > to avoid wasting irqs
    >
    > > Will it conflict?
    >
    > No in a sense that you can't bind both drivers to the same device.
    >
    > > In fact, it looks like you copied the comments for this driver directly
    > > from the pci-stub driver :)
    >
    > Right.
    >
    > > How about moving that documentation into a place that people will notice
    > > it, like the rest of the UIO documentation?
    >
    > OK.
    >
    > > And right now you are just sending the irq to userspace, what is
    > > userspace supposed to do with it?
    >
    > Userspace uses libpci (i.e. pci sysfs) to talk to the device and to
    > re-enable interrupts by writing to the command register.
    >
    > In the case of device assignment, this will be qemu which
    > acts as a proxy for driver running in guest context.
    > In case of uio loaded in guest, the driver will be in guest
    > userspace, and the device is emulated in qemu.
    >
    > > Do you have a userspace program that
    > > uses this interface today to verify that everything works? If so, care
    > > to provide a pointer to it?
    >
    > Sure. I used an emulated device for this.
    > First, you patch qemu to add the device:
    > http://www.linux-kvm.org/downloads/mst/test_irq.patch
    >
    > Now, run with the new kernel (-kernel flag), adding
    > -device test-irq
    >
    > Once in guest, assign the device id
    > echo "1af4 2009" > /sys/bus/pci/drivers/uio_pci_generic/new_id
    >
    > Compile and run this driver:
    > http://www.linux-kvm.org/downloads/mst/testuio.c
    > (it does not use any libraries besides libc,
    > so just gcc testuio.c -o testuio)
    >
    > And now make the device assert interrupts, like this:
    >
    > while
    > sleep 1
    > do
    > setpci -s 00:04.0 0x40.B=0x1
    > done
    >
    > You should see messages printed as the driver gets interrupts, but no
    > error messages about missed interrupts.
    >
    > > thanks,
    > >
    > > greg k-h
    >
    > --
    > To unsubscribe from this list: send the line "unsubscribe kvm" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html




    \
     
     \ /
      Last update: 2009-07-16 15:35    [W:0.030 / U:1.852 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site