From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Userspace hypercalls? Date: Mon, 27 Aug 2007 12:47:22 -0500 Message-ID: <1188236842.6364.18.camel@squirrel> References: <1188228447.12698.8.camel@squirrel> <46D2F8FA.6050104@qumranet.com> <46D2FCE1.7020605@qumranet.com> <46D3001A.9070706@qumranet.com> <1188235942.6364.12.camel@squirrel> <46D30BAE.4080705@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Avi Kivity Return-path: In-Reply-To: <46D30BAE.4080705-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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. > 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. Regards, Anthony Liguori > ------------------------------------------------------------------------- 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/