Anthony Liguori wrote: > On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote: > >> Anthony Liguori wrote: >> >>> On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote: >>> >>> >>>> Avi Kivity wrote: >>>> >>>> >>>>> Thinking a little more about this, it isn't about handling hypercalls >>>>> in userspace, but about handling a virtio sync() in userspace. >>>>> >>>>> So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's >>>>> event channel, but assymetric) that has a channel parameter. The >>>>> kernel handler for that hypercall dispatches calls to either a kernel >>>>> handler or a userspace handler. That means we don't need a separate >>>>> ETH_SEND, ETH_RECEIVE, or BLOCK_SEND hypercalls. >>>>> >>>>> >>>> And thinking a tiny little bit more about this, we can have the kernel >>>> (optionally) fire an eventfd, so a separate userspace thread or process >>>> can be woken up to service the device, without a heavyweight exit. >>>> >>>> >>> Yes, I think this is much nicer. By "calls to ... a userspace handler" >>> I presume you mean generating an exit to userspace with a new exit type >>> similar to how hypercalls work today? >>> >>> >>> >> There are two options: >> - hypercall handler sets some fields in vcpu->run and exits to userspace >> - hypercall handler triggers an eventfd and returns to guest >> >> Maybe we can unify the two by only allowing eventfd; >> > > Yes, that would be better except that the latency may be unacceptable. > >
Hmm. Good point. I keep saying kvm can have great I/O because the scheduler is not involved in ordinary I/O. Let's not break that. >> userspace can >> attach a signal to the eventfd if it wants a synchronous exit (does >> eventfd allow fcntl(F_SETOWN)?) >> > > Which would address the latency issue nicely. Looking at the fs code, > it looks like eventfd shouldn't have to do anything special for it. > I'm not sure now. Which thread will be selected for accepting the signal? if it isn't guaranteed to be the current thread, we're back with scheduler involvement, and possibly cacheline bouncing. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
