lkml.org 
[lkml]   [2009]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [KVM PATCH v4 3/3] kvm: add iosignalfd support
    Avi Kivity wrote:
    > Gregory Haskins wrote:
    >>
    >>> What happens if you register to iosignalfds for the same address but
    >>> with different cookies (a very practical scenario)?
    >>>
    >>
    >> This is really only supported at the iosignal interface level. Today,
    >> you can do this and the registration will succeed, but at run-time an
    >> IO-exit will stop at the first in_range() hit it finds. Therefore, you
    >> will only get service on the first/lowest registered range.
    >>
    >> I knew this was a limitation of the current io_bus, but I put the
    >> feature into iosignalfd anyway so that the user/kern interface was
    >> robust enough to support the notion should we ever need it (and can thus
    >> patch io_bus at that time). Perhaps that is short-sighted because
    >> userspace would never know its ranges weren't really registered
    >> properly.
    >>
    >> I guess its simple enough to have io_bus check all devices for a match
    >> instead of stopping on the first. Should I just make a patch to fix
    >> this, or should I fix iosignalfd to check for in_range matches and fail
    >> if it finds overlap? (We could then add a CAP_OVERLAP_IO bit in the
    >> future if we finally fix the io_bus capability). I am inclined to lean
    >> towards option 2, since its not known whether this will ever be useful,
    >> and io_bus scanning is in a hot-path.
    >>
    >> Thinking about it some more, I wonder if we should just get rid of the
    >> notion of overlap to begin with. Its a slippery slope (should we also
    >> return to userspace after scanning and matching io_bus to see if it has
    >> any overlap too?). I am not sure if it would ever be used (real
    >> hardware doesn't have multiple devices at the same address), and we can
    >> always have multiple end-points mux from one iosignalfd if we really
    >> need that. Thoughts?
    >>
    >
    > Multiple cookies on the same address are required by virtio. You
    > can't mux since the data doesn't go anywhere.

    Hmm..well, I might not be understanding properly, but I think we are
    still ok. IIUC, the concept is that we can register multiple
    iosignalfds to trigger when a single range of [MM|P]IO is touched. I.e.
    one iowrite() triggers multiple eventfd_signal()s to go out. You could
    do this directly by having io_bus support multiple matches for
    in_range(). You could also use a mux concept where one registration
    fans out to multiple iosignalfds (either like you suggest below, or by
    having one iosignalfd mux/relay to the others...I like your idea below
    better, btw).

    Or am I missing something?

    >
    >
    > Virtio can survive by checking all rings on a notify, and we can later
    > add a mechanism that has a distinct address for each ring, but let's
    > see if we can cope with multiple cookies. Mark?

    I am confused by this. I can totally see the use case for one
    iosignalfd (w/ one address) for all rings (in a device), and one
    iosignalfd per ring (each with a unique address). But when would we
    want to have one address serve multiple rings each with their own
    notification? Just curious.

    >
    >
    > You could search existing iosignalfds for the same address and re-use
    > the same iodevice. I don't want to search the entire list since that
    > precludes tricks like using hashtables or sorting the list by
    > frequency of access.
    >
    Yeah, I like this idea best. I can basically have my own "in_range"
    mechanism inside the _iosignalfd structure. I only register one range
    with io_bus, but then I may have multiple targets within that. I will
    do this for v5.

    -Greg



    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2009-05-27 14:57    [W:0.025 / U:0.400 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site