lkml.org 
[lkml]   [2009]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC v2] virtio: add virtio-over-PCI driver
    Date
    On Thursday 26 February 2009, Ira Snyder wrote:
    > On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
    >
    > The registers are part of the board control registers. They don't fit at
    > all in the message unit. Doing this in the bootloader seems like a
    > logical place, but that would require any testers to flash a new U-Boot
    > image into their mpc8349emds boards.
    >
    > The first set of access is used to set up a 1GB region in the memory map
    > that accesses the host's memory. Any reads/writes to addresses
    > 0x80000000-0xc0000000 actually hit the host's memory.
    >
    > The last access sets up PCI BAR1 to hit the memory from
    > dma_alloc_coherent(). The bootloader already sets up the window as 16K,
    > it just doesn't point it anywhere. Maybe this /should/ go into the
    > bootloader. Like above, it would require testers to flash a new U-Boot
    > image into their mpc8349emds boards.

    Ok, I see.

    I guess the best option for doing it in Linux then would be to have
    a board control driver (not sure if this already exists) that exports
    high-level functions to set up the inbound and outbound windows.

    > Yeah, virtio doesn't work that way.
    >
    > The virtio drivers just call find_vq() with a different index for each
    > queue they want to use. You have no way of knowing how many queues each
    > virtio driver will want, unless you go read their source code.
    >
    > virtio-net currently uses 3 queues, but we only support the first two.
    > The third is optional (for now...), and non-symmetric.

    I mean the part of your driver that calls register_virtio_device()
    could make the decision, this is the one I was referring to
    as virtio_net glue because it is the only part that actually needs
    to know about the features etc.

    Right now, you just call register_virtio_net from vop_probe(), which
    is absolutely appropriate for the specific use case. In the most
    general case though, you would have a user interface on one or
    both sides that allows a (root) user to trigger the creation of
    a virtio_net (or other virtio) device with specific characteristics
    such as MAC address or number of virtqueues.

    One idea I had earlier was that there could be a special device
    with just one virtqueue that is always present and that allows you
    do communicate configuration changes regarding the available devices
    to the remote VOP driver.

    Arnd <><


    \
     
     \ /
      Last update: 2009-02-26 23:37    [W:6.171 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site