From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLEnB-0002rP-57 for qemu-devel@nongnu.org; Mon, 08 Oct 2012 10:58:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLEmv-0004Mk-Tr for qemu-devel@nongnu.org; Mon, 08 Oct 2012 10:58:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLEmv-0004Le-JD for qemu-devel@nongnu.org; Mon, 08 Oct 2012 10:58:33 -0400 Message-ID: <5072EA14.30809@redhat.com> Date: Mon, 08 Oct 2012 16:58:28 +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> In-Reply-To: <87bogddq0l.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, > But I think we could solve this in a different way. I think we could > just move the virtio configuration space to BAR1 by using a transport > feature bit. Why hard-code stuff? I think it makes alot of sense to have a capability simliar to msi-x which simply specifies bar and offset of the register sets: [root@fedora ~]# lspci -vvs4 00:04.0 SCSI storage controller: Red Hat, Inc Virtio block device [ ... ] Region 0: I/O ports at c000 [size=64] Region 1: Memory at fc029000 (32-bit) [size=4K] Capabilities: [40] MSI-X: Enable+ Count=2 Masked- Vector table: BAR=1 offset=00000000 PBA: BAR=1 offset=00000800 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 > That then frees up the entire BAR0 for use as virtio-pci registers. We > can then always include the virtio-pci MSI-X register space and > introduce all new virtio-pci registers as simply being appended. BAR0 needs to stay as-is for compatibility reasons. New devices which don't have to care about old guests don't need to provide a 'legacy' register region. Most devices have mmio at BAR1 for msi-x support anyway, we can place the virtio-pci and virtio configuration registers there too by default. I wouldn't hardcode that though. > This new feature bit then becomes essentially a virtio configuration > latch. When unacked, virtio configuration hides new registers, when > acked, those new registers are exposed. I'd just expose them all all the time. >> 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 ... cheers, Gerd