From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET Date: Wed, 06 Jul 2011 15:39:31 +0300 Message-ID: <4E145783.2000605@redhat.com> References: <1309927078-5983-1-git-send-email-levinsasha928@gmail.com> <1309927078-5983-5-git-send-email-levinsasha928@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti , "Michael S. Tsirkin" , Pekka Enberg To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51805 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753145Ab1GFMjm (ORCPT ); Wed, 6 Jul 2011 08:39:42 -0400 In-Reply-To: <1309927078-5983-5-git-send-email-levinsasha928@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/06/2011 07:37 AM, Sasha Levin wrote: > The new flag allows passing a connected socket instead of an > eventfd to be notified of writes or reads to the specified memory region. > > Instead of signaling an event, On write - the value written to the memory > region is written to the pipe. > On read - a notification of the read is sent to the host, and a response > is expected with the value to be 'read'. > > Using a socket instead of an eventfd is usefull when any value can be > written to the memory region but we're interested in recieving the > actual value instead of just a notification. > > A simple example for practical use is the serial port. we are not > interested in an exit every time a char is written to the port, but > we do need to know what was written so we could handle it on the guest. > > > > @@ -534,6 +607,7 @@ ioeventfd_read(struct kvm_io_device *this, gpa_t addr, int len, > void *val) > { > struct _ioeventfd *p = to_ioeventfd(this); > + struct kvm_ioeventfd_data data; > > /* Exit if signaling on reads isn't requested */ > if (!p->track_reads) > @@ -542,7 +616,21 @@ ioeventfd_read(struct kvm_io_device *this, gpa_t addr, int len, > if (!ioeventfd_in_range(p, addr, len, val)) > return -EOPNOTSUPP; > > - eventfd_signal(p->eventfd, 1); > + data = (struct kvm_ioeventfd_data) { > + .addr = addr, > + .len = len, > + .is_write = 0, > + }; > + > + if (p->sock) { > + socket_write(p->sock,&data, sizeof(data)); > + socket_read(p->sock,&data, sizeof(data)); > + set_val(val, len, data.data); > + } else { > + set_val(val, len, p->datamatch); > + eventfd_signal(p->eventfd, 1); > + } > + > return 0; > } If there are two reads on the same ioeventfd range, then the responses can mix up. Need to make sure we get the right response. Note that a mutex on the ioeventfd structure is insufficient, since the same socket may be used for multiple ranges. One way out is to require that sockets not be shared among vcpus (there can be only one outstanding read per vcpu). It seems heavy handed though. -- error compiling committee.c: too many arguments to function