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.
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?
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.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
