From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLxc5-0000Wb-Hl for qemu-devel@nongnu.org; Thu, 03 Nov 2011 09:45:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLxc1-0000oX-3M for qemu-devel@nongnu.org; Thu, 03 Nov 2011 09:45:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLxc0-0000oT-Oe for qemu-devel@nongnu.org; Thu, 03 Nov 2011 09:45:45 -0400 Message-ID: <4EB29B00.10907@redhat.com> Date: Thu, 03 Nov 2011 15:45:36 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1317360376-12090-1-git-send-email-david@gibson.dropbear.id.au> <4EB07096.4070806@us.ibm.com> <4EB26EA5.4060606@redhat.com> <4EB291F4.8070503@us.ibm.com> <4EB29381.9060707@redhat.com> <4EB2993C.9000902@codemonkey.ws> In-Reply-To: <4EB2993C.9000902@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: rusty@rustcorp.com.au, "Michael S. Tsirkin" , qemu-devel@nongnu.org, David Gibson On 11/03/2011 03:38 PM, Anthony Liguori wrote: >> >>> We could use a better agreement on the processor for making virtio >>> changes. Should it go (1) virtio spec (2) kernel (3) qemu, or should >>> it go (2), (1), (3)? >> >> 1. Informal discussion > > > Where? Is this lkml? There were a number of virtio changes recently > that never involved qemu-devel. Theoretically, virtualization@lists.linux-foundation.org, if it still exists. Maybe we need a virtio list. qemu-devel@, kvm@, lkml could be copied. The point is that we can't drive virtio from either qemu or the kernel any more. The spec represents the "virtual hardware manufacturer", which qemu and linux/vhost (and others) emulate, and which linux (and others) write drivers for. > >> 2. Proposed spec patch, kernel change, qemu change >> 3. Buy-ins from spec maintainer, kernel driver maintainer, qemu device >> maintainer (only regarding the ABI, not the code) > > I don't think this is how it's working today. I would be happy with a > flow like this. If Michael and Rusty agree, we can adopt it immediately. -- error compiling committee.c: too many arguments to function