From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LzbuS-0003U9-D1 for qemu-devel@nongnu.org; Thu, 30 Apr 2009 15:27:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LzbuN-0003Tl-9a for qemu-devel@nongnu.org; Thu, 30 Apr 2009 15:27:03 -0400 Received: from [199.232.76.173] (port=58079 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LzbuN-0003Ti-1e for qemu-devel@nongnu.org; Thu, 30 Apr 2009 15:26:59 -0400 Received: from mx2.redhat.com ([66.187.237.31]:46186) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LzbuM-0000pP-Jx for qemu-devel@nongnu.org; Thu, 30 Apr 2009 15:26:58 -0400 Date: Thu, 30 Apr 2009 16:26:44 -0300 From: Marcelo Tosatti Message-ID: <20090430192644.GA4790@amt.cnet> 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-Disposition: inline In-Reply-To: <20090430172955.GA16925@redhat.com> Subject: [Qemu-devel] Re: questions on default_config_write in hw/pci.c List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , Avi Kivity , qemu-devel@nongnu.org On Thu, Apr 30, 2009 at 08:29:55PM +0300, Michael S. Tsirkin wrote: > 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." > > > > 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? The first 16 bytes of the config space are common (which include vendor/device). But some refactoring to have the header specific part into separate functions would be nice? Anthony: it did work for me, all 128 slots.