qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: questions on default_config_write in hw/pci.c


From: M. Warner Losh
Subject: Re: [Qemu-devel] Re: questions on default_config_write in hw/pci.c
Date: Thu, 30 Apr 2009 22:50:56 -0600 (MDT)

In message: <address@hidden>
            "Michael S. Tsirkin" <address@hidden> 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/address@hidden/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
: 
: 
: 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]