From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YT6yC-0002lo-V9 for qemu-devel@nongnu.org; Wed, 04 Mar 2015 05:56:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YT6y4-0004T8-TN for qemu-devel@nongnu.org; Wed, 04 Mar 2015 05:56:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YT6y4-0004RF-HD for qemu-devel@nongnu.org; Wed, 04 Mar 2015 05:55:56 -0500 Message-ID: <1425466550.8389.10.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Wed, 04 Mar 2015 11:55:50 +0100 In-Reply-To: <20150303174201.GD21824@redhat.com> References: <1425390913-17726-1-git-send-email-kraxel@redhat.com> <20150303174201.GD21824@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] virtio-pci: make pci bar layout more flexible. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, Anthony Liguori Hi, > > VirtIOPCIProxy subclasses which need additional pci bars, such as > > virtio-vga, just need to make sure they register the additinal bars > > before initializing virtio-pci, so the superclass can see the registered > > bars and shuffle around the virtio bars accordingly. > > I think I prefer we just DTRT and keep same layouts for everyone by > default: isn't there a layout that is good for everybody? I want bar #2 for the vga framebuffer for virtio-vga. Which conflicts with bar #2 being used for the modern bar in todays code. We can move the modern bar to #4 for everybody, then we'll have: #0 -- legacy i/o #1 -- msix #2 -- unused (by virtio) #3 -- unused (by virtio) #4 -- modern mem #5 -- modern mem too (because it's 64bit). That'll leave bars #2 + #3 free, for additional bars (1x 64bit or 2x 32bit) such as vga framebuffer if needed. > I know this means we'll leave BAR0 unused for modern devices but that > does not seem too bad. Yep, no technical reason against it, although it IMHO looks nicer. cheers, Gerd