From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mkvck-0005Bu-MR for qemu-devel@nongnu.org; Tue, 08 Sep 2009 04:00:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mkvcg-00057g-8P for qemu-devel@nongnu.org; Tue, 08 Sep 2009 04:00:22 -0400 Received: from [199.232.76.173] (port=58985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mkvcf-00057I-NC for qemu-devel@nongnu.org; Tue, 08 Sep 2009 04:00:17 -0400 Received: from mx20.gnu.org ([199.232.41.8]:5013) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mkvcf-0001tP-A5 for qemu-devel@nongnu.org; Tue, 08 Sep 2009 04:00:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mkvce-0000Cr-2I for qemu-devel@nongnu.org; Tue, 08 Sep 2009 04:00:16 -0400 Date: Tue, 8 Sep 2009 10:58:31 +0300 From: "Michael S. Tsirkin" Message-ID: <20090908075831.GA9875@redhat.com> References: <20090907181436.GA8538@redhat.com> <4AA60A58.4090703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA60A58.4090703@redhat.com> Subject: [Qemu-devel] Re: [PATCH] qemu: make virtio-blk PCI compliant by default List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: john cooper Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, jens.axboe@oracle.com On Tue, Sep 08, 2009 at 03:40:08AM -0400, john cooper wrote: > Michael S. Tsirkin wrote: > > commit bf011293faaa7f87e4de83185931e7411b794128 made virtio-blk-pci not > > PCI-compliant, since it makes region 0 (which is an i/o region) > > size > 256, and, since PCI 2.1, i/o regions are limited to 256 bytes size. > > > > When the ATA serial number feature is off, which is the default, > > make the device spec compliant again, by making region 0 smaller. > > I'd hazard this is the cause of the breakage others > encountered -- even when the driver was initialized > but unused. For some odd reason I hadn't seen nor > been able to reproduce the failure. > > The mock-up of an entire ATA IDENTIFY page is really > overkill for what we're trying to accomplish here, > namely passing a 20 byte S/N from qemu to the guest. > However emulating and passing an IDENTIFY page allows > guest apps to interpret the information via an > existing interface, with the guest driver doing nothing > more than transferring the data as opaque. During > review, other defined fields of the IDENTIFY page were > speculated to be potentially useful thus the entire > 512 byte page was passed wholesale. But it is clearly > more trouble than benefit at this point. I'll rework > the patch or use an alternate mechanism. BTW, will the change you have in mind affect the guest driver as well? If yes, maybe revert 1d589bb16b825b3a7b4edd34d997f1f1f953033d in linux before 2.6.31 is out? Otherwise we'll be stuck supporting the bad interface from upstream 2.6.31 in upstream qemu ... > -john > > -- > john.cooper@redhat.com