From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LzkkY-0008MR-JZ for qemu-devel@nongnu.org; Fri, 01 May 2009 00:53:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LzkkT-0008Ix-Nk for qemu-devel@nongnu.org; Fri, 01 May 2009 00:53:26 -0400 Received: from [199.232.76.173] (port=43462 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LzkkT-0008Iu-J0 for qemu-devel@nongnu.org; Fri, 01 May 2009 00:53:21 -0400 Received: from bsdimp.com ([199.45.160.85]:55294 helo=harmony.bsdimp.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LzkkT-00047W-22 for qemu-devel@nongnu.org; Fri, 01 May 2009 00:53:21 -0400 Date: Thu, 30 Apr 2009 22:50:56 -0600 (MDT) Message-Id: <20090430.225056.226731817.imp@bsdimp.com> Subject: Re: [Qemu-devel] Re: questions on default_config_write in hw/pci.c From: "M. Warner Losh" In-Reply-To: <20090430172955.GA16925@redhat.com> References: <20090430161508.GA15893@redhat.com> <20090430171526.GA10638@amt.cnet> <20090430172955.GA16925@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mst@redhat.com Cc: aliguori@us.ibm.com, mtosatti@redhat.com, avi@redhat.com, qemu-devel@nongnu.org In message: <20090430172955.GA16925@redhat.com> "Michael S. Tsirkin" writes: : On Thu, Apr 30, 2009 at 02:15:26PM -0300, Marcelo Tosatti wrote: : > On Thu, Apr 30, 2009 at 07:15:08PM +0300, Michael S. Tsirkin wrote: : > > Hi, : > > I've been looking at hw/pci.c, specifically at how config : > > read/write are implemented, and have a couple of questions : > > about default_config_write: : > > : > > 1. The code at the beginning (if len == 4 ...) : > > seems to only update pci base registers if a dword write : > > is performed. I think it's legal for the guest to perform 4 : > > single-byte writes. Should this be supported? : > > : > > 2. The large switch statement at the end of this function : > > uses hard-coded register offsets. Would it make sense : > > to change it to use macros from hw/pci.h? : > > : > > 3. Still there I see: : > > switch(d->config[0x0e]) { : > > case 0x00: : > > case 0x80: : > > register 0x0e is header type, which has defined values : > > of 0x00 (device or host bridge), 0x01 (pci to pci bridge) and : > > 0x02 (cardbus bridge). What is 0x80 and when is it used? : > > Would it make sense to remove this? : > : > Don't know. Check the PCI spec? : : That's the first thing I did :) What I site above is from there: : "The Header Type field (located at offset 0Eh) defines what layout is : provided. Currently three Header Types are defined, 00h which has the : layout shown in Figure 6-1, 01h which is defined for PCI-to-PCI bridges : and is documented in the PCI to PCI Bridge Architecture Specification, : and 02h which is defined for CardBus bridges and is documented in the PC : Card Standard." Section 6.2.1: Header Type This byte identifies the layout of the second part of the predefined header (beginning at byte 10h in Configuration Space) and also whether or not the device contains multiple functions. Bit 7 in this register is used to identify multi-function device. If the bit is 0, then the device is single function. If the bit is 1, then the device has multiple functions. : > > 4. Still there, there's some handling done for type 1 devices. : > > This support seems imcomplete. : > > Are there any PCI-to-PCI bridges emulated by qemu? : > > Would it make sense to remove this code? : > : > : > It did work at one point: : > : > http://www.mail-archive.com/kvm-devel@lists.sourceforge.net/msg16647.html : : Sigh. I guess I'll have to fix it rather than just rip it out then ... : What I refer to first of all is that writes to BAR registers go through : logic for regular PCI devices, which have a different layout. : Does this make sense for some reason? : : -- : MST : : :