From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsfVa-0000OE-KU for qemu-devel@nongnu.org; Tue, 29 Sep 2009 12:24:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsfVV-0000LQ-Ms for qemu-devel@nongnu.org; Tue, 29 Sep 2009 12:24:57 -0400 Received: from [199.232.76.173] (port=38039 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsfVV-0000LG-Es for qemu-devel@nongnu.org; Tue, 29 Sep 2009 12:24:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22878) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsfVU-0002Vq-L8 for qemu-devel@nongnu.org; Tue, 29 Sep 2009 12:24:52 -0400 Message-ID: <4AC234CF.6030902@redhat.com> Date: Tue, 29 Sep 2009 18:24:47 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4AB8DD53.7070806@redhat.com> <4AB8DECA.3090908@redhat.com> <4AB8E88C.4040103@redhat.com> <4AB980E6.2070203@codemonkey.ws> <4AB9AA8E.7060800@third-harmonic.com> <4AC1A49A.1010308@redhat.com> <20090929065856.GC25389@redhat.com> <4AC1B5CD.7050702@redhat.com> <20090929085450.GE25389@redhat.com> <4AC211C8.1060202@codemonkey.ws> <20090929140601.GA28733@redhat.com> <4AC21660.6020304@codemonkey.ws> In-Reply-To: <4AC21660.6020304@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/2] fix virtio_blk serial pci config breakage 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, Vadim Rozenfeld , jens.axboe@oracle.com On 09/29/2009 04:14 PM, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> I don't think it's such a good idea. We want to keep exposing most of >> config space in i/o bar because of backwards compatibility. And we want >> to keep datapath operations such as vq kicks, in i/o space. > > We can do feature negotiation in virtio-pci. That lets us continue > exposing the first 246 bytes of the config space in PIO and guests can > negotiate a second bar for access to larger config spaces. Shouldn't the guest's pci layer automatically adapt to what the card throws at it? Of course we need to keep migration compatibility so we need to keep pio. -- error compiling committee.c: too many arguments to function