From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqL05-0001hK-9w for qemu-devel@nongnu.org; Wed, 23 Sep 2009 02:06:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqL00-0001do-5Y for qemu-devel@nongnu.org; Wed, 23 Sep 2009 02:06:48 -0400 Received: from [199.232.76.173] (port=58764 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqKzz-0001df-Rs for qemu-devel@nongnu.org; Wed, 23 Sep 2009 02:06:43 -0400 Received: from dpc6682208002.direcpc.com ([66.82.208.2]:38758 helo=anvil.third-harmonic.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqKzy-00020p-1M for qemu-devel@nongnu.org; Wed, 23 Sep 2009 02:06:43 -0400 Message-ID: <4AB9AA8E.7060800@third-harmonic.com> Date: Wed, 23 Sep 2009 00:56:46 -0400 From: john cooper 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> <4AB8E88C.4040103@redhat.com> <4AB980E6.2070203@codemonkey.ws> In-Reply-To: <4AB980E6.2070203@codemonkey.ws> 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: Anthony Liguori Cc: john cooper , "Michael S. Tsirkin" , john cooper , Rusty Russell , qemu-devel@nongnu.org, Avi Kivity , jens.axboe@oracle.com Anthony Liguori wrote: > john cooper wrote: >> Avi Kivity wrote: >> >>> On 09/22/2009 05:21 PM, john cooper wrote: >>> >>>>> Can we just read this page as a virtqueue command instead of having it >>>>> mapped permanently? >>>>> >>>> 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. >>> >> >> Agreed. However my motivation here was to use a >> single additional bar specifically to compensate >> for the PCI spec imposed 256 byte size limitation >> of the config space mapping. As we're defining the >> content/size of this area, future use to accommodate >> additional data should be unrestricted. >> > > Why expose the whole ATAPI page instead of just the serial number? Exposing the s/n alone was what I'd done originally which in retrospect was well contained within the pci config area -- even if squandering the somewhat limited space in that area. However exposing it as an identify page allows use of the existing HDIO_GET_IDENTITY ioctl (and existing use of that interface, eg: "hdparm -i") as a means to extract the s/n along with potentially useful related data in the page. Creation of the identify structure is within qemu as that is where the information exists. And this allows the virtio_blk driver to treat the data as opaque, simply exporting it uninterpreted via a copyout. So the only real issue remaining is how to best saw a hole between qemu and the guest virtio_blk driver to transfer the identity data. > I think the proper solution is to move the config to a separate bar > that's MMIO instead of PIO. config access is never performance > sensitive and an MMIO bar has less restrictions on size. That's exactly what I've done. I'll clean up the patch and post it here so we can have a more concrete discussion. -john -- john.cooper@third-harmonic.com