From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [KVM PATCH v4 3/3] kvm: add iosignalfd support Date: Wed, 27 May 2009 15:11:04 +0300 Message-ID: <4A1D2DD8.2050709@redhat.com> References: <20090526191010.20860.75372.stgit@dev.haskins.net> <20090526191539.20860.1385.stgit@dev.haskins.net> <4A1D01F8.8080508@redhat.com> <4A1D285C.9050008@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Davide Libenzi , mtosatti@redhat.com, Mark McLoughlin To: Gregory Haskins Return-path: In-Reply-To: <4A1D285C.9050008@novell.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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