From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLJhw-0005w5-Ce for qemu-devel@nongnu.org; Mon, 08 Oct 2012 16:13:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLJhv-0004TT-Bz for qemu-devel@nongnu.org; Mon, 08 Oct 2012 16:13:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLJhv-0004TN-3N for qemu-devel@nongnu.org; Mon, 08 Oct 2012 16:13:43 -0400 Message-ID: <507333F1.1060000@redhat.com> Date: Mon, 08 Oct 2012 22:13:37 +0200 From: Gerd Hoffmann 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> In-Reply-To: <87k3v1gfw1.fsf@codemonkey.ws> 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: Anthony Liguori Cc: Rusty Russell , virtualization@lists.linux-foundation.org, qemu-devel , kvm@vger.kernel.org, "Michael S. Tsirkin" Hi, >> So we could have for virtio something like this: >> >> Capabilities: [??] virtio-regs: >> legacy: BAR=0 offset=0 >> virtio-pci: BAR=1 offset=1000 >> virtio-cfg: BAR=1 offset=1800 > > This would be a vendor specific PCI capability so lspci wouldn't > automatically know how to parse it. Sure, would need a patch to actually parse+print the cap, /me was just trying to make my point clear in a simple way. >>>> 2) ISTR an argument about mapping the ISR register separately, for >>>> performance, but I can't find a reference to it. >>> >>> I think the rationale is that ISR really needs to be PIO but everything >>> else doesn't. PIO is much faster on x86 because it doesn't require >>> walking page tables or instruction emulation to handle the exit. >> >> Is this still a pressing issue? With MSI-X enabled ISR isn't needed, >> correct? Which would imply that pretty much only old guests without >> MSI-X support need this, and we don't need to worry that much when >> designing something new ... > > It wasn't that long ago that MSI-X wasn't supported.. I think we should > continue to keep ISR as PIO as it is a fast path. No problem if we allow to have both legacy layout and new layout at the same time. Guests can continue to use ISR @ BAR0 in PIO space for existing virtio devices, even in case they want use mmio for other registers -> all fine. New virtio devices can support MSI-X from day one and decide to not expose a legacy layout PIO bar. cheers, Gerd