From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [Qemu-devel] Questions regarding ivshmem spec Date: Thu, 25 Aug 2011 17:39:06 +0300 Message-ID: <1314283146.3692.59.camel@lappy> References: <1314278954.3692.55.camel@lappy> <4E56556E.1080805@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: cam , David Evensky , Pekka Enberg , qemu-devel , kvm To: Avi Kivity Return-path: Received: from mail-fx0-f46.google.com ([209.85.161.46]:53428 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752188Ab1HYOjK (ORCPT ); Thu, 25 Aug 2011 10:39:10 -0400 Received: by fxh19 with SMTP id 19so1799265fxh.19 for ; Thu, 25 Aug 2011 07:39:09 -0700 (PDT) In-Reply-To: <4E56556E.1080805@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 2011-08-25 at 17:00 +0300, Avi Kivity wrote: > On 08/25/2011 04:29 PM, Sasha Levin wrote: > > 2. The spec describes DOORBELL as an array of DWORDs, when one guest > > wants to poke a different guest it would write something into the offset > > of the other guest in the DOORBELL array. > > Looking at the implementation in QEMU, DOORBELL is one DWORD, when > > writing to it the upper WORD is the guest id and the lower WORD is the > > value. > > What am I missing here? > > > > The spec in qemu.git is accurate. The intent is to use an ioeventfd > bound into an irqfd so a write into the doorbell injects an interrupt > directly into the other guest, without going through qemu^Wkvm tool. > But the doorbell is a single DWORD, so if a guest writes to it we'd still need to figure out which guest/vector he wants to poke from userspace, no? If it was an array of doorbells then yes, we could assign an ioeventfd to each offset - but now I don't quite see how we can avoid passing through the userspace. -- Sasha. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwb5P-000190-Bf for qemu-devel@nongnu.org; Thu, 25 Aug 2011 10:39:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qwb5K-0004eN-90 for qemu-devel@nongnu.org; Thu, 25 Aug 2011 10:39:15 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:57607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwb5K-0004eJ-1J for qemu-devel@nongnu.org; Thu, 25 Aug 2011 10:39:10 -0400 Received: by fxbb27 with SMTP id b27so2030725fxb.4 for ; Thu, 25 Aug 2011 07:39:09 -0700 (PDT) From: Sasha Levin In-Reply-To: <4E56556E.1080805@redhat.com> References: <1314278954.3692.55.camel@lappy> <4E56556E.1080805@redhat.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Aug 2011 17:39:06 +0300 Message-ID: <1314283146.3692.59.camel@lappy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Questions regarding ivshmem spec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Pekka Enberg , cam , qemu-devel , David Evensky , kvm On Thu, 2011-08-25 at 17:00 +0300, Avi Kivity wrote: > On 08/25/2011 04:29 PM, Sasha Levin wrote: > > 2. The spec describes DOORBELL as an array of DWORDs, when one guest > > wants to poke a different guest it would write something into the offset > > of the other guest in the DOORBELL array. > > Looking at the implementation in QEMU, DOORBELL is one DWORD, when > > writing to it the upper WORD is the guest id and the lower WORD is the > > value. > > What am I missing here? > > > > The spec in qemu.git is accurate. The intent is to use an ioeventfd > bound into an irqfd so a write into the doorbell injects an interrupt > directly into the other guest, without going through qemu^Wkvm tool. > But the doorbell is a single DWORD, so if a guest writes to it we'd still need to figure out which guest/vector he wants to poke from userspace, no? If it was an array of doorbells then yes, we could assign an ioeventfd to each offset - but now I don't quite see how we can avoid passing through the userspace. -- Sasha.