From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLExR-0006rj-AT for qemu-devel@nongnu.org; Mon, 08 Oct 2012 11:09:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLExM-0008Ug-Iy for qemu-devel@nongnu.org; Mon, 08 Oct 2012 11:09:25 -0400 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:50766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLExM-0008UR-1V for qemu-devel@nongnu.org; Mon, 08 Oct 2012 11:09:20 -0400 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 9 Oct 2012 01:07:32 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q98ExNqa65142854 for ; Tue, 9 Oct 2012 01:59:27 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q98F9Ao1014708 for ; Tue, 9 Oct 2012 02:09:10 +1100 From: Anthony Liguori In-Reply-To: <5072EA14.30809@redhat.com> References: <87zk4c2tqq.fsf@rustcorp.com.au> <874nmajcmj.fsf@codemonkey.ws> <87y5jhpuu2.fsf@rustcorp.com.au> <87bogddq0l.fsf@codemonkey.ws> <5072EA14.30809@redhat.com> Date: Mon, 08 Oct 2012 10:09:02 -0500 Message-ID: <87k3v1gfw1.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Gerd Hoffmann Cc: Rusty Russell , virtualization@lists.linux-foundation.org, qemu-devel , kvm@vger.kernel.org, "Michael S. Tsirkin" Gerd Hoffmann writes: > 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 MSI-X capability is a standard PCI capability which is why lspci can parse it. > > 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. You could just as well teach lspci to parse BAR0 to figure out what features are supported. >> 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. A latch feature bit would allow the format to change without impacting compatibility at all. >>> 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. Regards, Anthony Liguori > > cheers, > Gerd > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html