From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLWt6-0000lt-QP for qemu-devel@nongnu.org; Tue, 09 Oct 2012 06:18:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLWt0-0007np-Vz for qemu-devel@nongnu.org; Tue, 09 Oct 2012 06:18:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLWt0-0007nk-LU for qemu-devel@nongnu.org; Tue, 09 Oct 2012 06:18:02 -0400 Message-ID: <5073F9D4.5060000@redhat.com> Date: Tue, 09 Oct 2012 12:17:56 +0200 From: Avi Kivity MIME-Version: 1.0 References: <87zk4c2tqq.fsf@rustcorp.com.au> <874nmajcmj.fsf@codemonkey.ws> <87y5jhpuu2.fsf@rustcorp.com.au> <87bogddq0l.fsf@codemonkey.ws> <5072EA14.30809@redhat.com> <87k3v1gfw1.fsf@codemonkey.ws> <507333F1.1060000@redhat.com> <874nm4u1in.fsf@codemonkey.ws> <87sj9o8qn7.fsf@rustcorp.com.au> <87sj9oh0pm.fsf@codemonkey.ws> <87haq48hds.fsf@rustcorp.com.au> In-Reply-To: <87haq48hds.fsf@rustcorp.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Using PCI config space to indicate config location List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: Anthony Liguori , kvm@vger.kernel.org, "Michael S. Tsirkin" , qemu-devel , virtualization@lists.linux-foundation.org, Gerd Hoffmann On 10/09/2012 05:16 AM, Rusty Russell wrote: > Anthony Liguori writes: >> We'll never remove legacy so we shouldn't plan on it. There are >> literally hundreds of thousands of VMs out there with the current virtio >> drivers installed in them. We'll be supporting them for a very, very >> long time :-) > > You will be supporting this for qemu on x86, sure. As I think we're > still in the growth phase for virtio, I prioritize future spec > cleanliness pretty high. If a pure ppc hypervisor was on the table, this might have been worthwhile. As it is the codebase is shared, and the Linux drivers are shared, so cleaning up the spec doesn't help the code. > > But I think you'll be surprised how fast this is deprecated: > 1) Bigger queues for block devices (guest-specified ringsize) > 2) Smaller rings for openbios (guest-specified alignment) > 3) All-mmio mode (powerpc) > 4) Whatever network features get numbers > 31. > >> I don't think we gain a lot by moving the ISR into a separate BAR. >> Splitting up registers like that seems weird to me too. > > Confused. I proposed the same split as you have, just ISR by itself. I believe Anthony objects to having the ISR by itself. What is the motivation for that? -- error compiling committee.c: too many arguments to function