From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mq6cu-0006YL-GV for qemu-devel@nongnu.org; Tue, 22 Sep 2009 10:45:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mq6cp-0006Vg-Fe for qemu-devel@nongnu.org; Tue, 22 Sep 2009 10:45:55 -0400 Received: from [199.232.76.173] (port=58237 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq6cp-0006Vb-AU for qemu-devel@nongnu.org; Tue, 22 Sep 2009 10:45:51 -0400 Received: from mx20.gnu.org ([199.232.41.8]:14637) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mq6co-00021M-Pt for qemu-devel@nongnu.org; Tue, 22 Sep 2009 10:45:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mq6cn-0005Oi-MQ for qemu-devel@nongnu.org; Tue, 22 Sep 2009 10:45:49 -0400 Message-ID: <4AB8E319.6020804@redhat.com> Date: Tue, 22 Sep 2009 17:45:45 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] qemu: make virtio-blk PCI compliant by default References: <20090907181436.GA8538@redhat.com> <4AA60A58.4090703@redhat.com> <20090908075831.GA9875@redhat.com> <200909212039.01126.rusty@rustcorp.com.au> <4AB7A01A.3000206@redhat.com> <4AB8992B.7070709@redhat.com> <4AB8DD53.7070806@redhat.com> <4AB8DECA.3090908@redhat.com> <20090922144147.GA4117@redhat.com> In-Reply-To: <20090922144147.GA4117@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: john cooper , Rusty Russell , qemu-devel@nongnu.org, jens.axboe@oracle.com On 09/22/2009 05:41 PM, Michael S. Tsirkin wrote: >>> >>> Probably although I hadn't looked specifically >>> at doing so. Mapping the data via an unused >>> pci bar is pretty trivial and seemed minimally >>> intrusive to the existing driver. >>> >>> >> We'll run out of bars if we expend them like that. >> > BAR1 is used for MSI-X already (if MSI-X is enabled), you can just add > your data there. I would report the offset within the BAR somewhere > in io space or in configuration space, so that we can relocate tables > later if we like without changing guests. > I'd really like to avoid such entanglements. -- error compiling committee.c: too many arguments to function