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; userspace can attach a signal to the eventfd if it wants a synchronous exit (does eventfd allow fcntl(F_SETOWN)?) -- 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
