From: Isaku Yamahata <yamahata@valinux.co.jp>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: blauwirbel@gmail.com, yu.liu@freescale.com,
qemu-devel@nongnu.org, aurelien@aurel32.net,
paul@codesourcery.com
Subject: Re: [Qemu-devel] Re: [PATCH v4 3/6] pci: set PCI multi-function bit appropriately.
Date: Wed, 23 Jun 2010 19:13:38 +0900 [thread overview]
Message-ID: <20100623101338.GD3471@valinux.co.jp> (raw)
In-Reply-To: <20100623095210.GA9802@redhat.com>
On Wed, Jun 23, 2010 at 12:52:10PM +0300, Michael S. Tsirkin wrote:
> > > > @@ -575,6 +576,44 @@ static void pci_init_wmask_bridge(PCIDevice *d)
> > > > pci_set_word(d->wmask + PCI_BRIDGE_CONTROL, 0xffff);
> > > > }
> > > >
> > > > +static int pci_init_multifunction(PCIBus *bus, PCIDevice *dev)
> > > > +{
> > >
> > > IMO we should just add in pci_register_device:
> > >
> > > if (d->cap_resent & QEMU_PCI_CAP_MULTIFUNCTION) {
> > > dev->config[PCI_HEADER_TYPE] |= PCI_HEADER_TYPE_MULTI_FUNCTION;
> > > } else if (PCI_FUNC(dev->devfn)) {
> > > error_report("PCI: single function device can't be populated %x.%x",
> > > PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
> > > return -1;
> > > }
> > >
> > > And be done with it.
> >
> > Unfortunately there are two ways to set the bit.
> > - set the bit of all the function.
> > Example: Intel X58(north bridge.)
> > - set the bit of only function = 0.
> > Example: PIIX3, PIIX4, ... ICH10.
> >
> > lspci -x would help to see what your pc has.
>
> This is correct:
> The order in which configuration software probes devices residing on a
> bus segment is not specified. Typically, configuration software either
> starts with Device Number 0 and works up or starts at Device Number 31
> and works down. If a single function device is detected (i.e., bit 7 in
> the Header Type register of function 0 is 0), no more functions for that
> Device Number will be checked. If a multi-function device is detected
> (i.e., bit 7 in the Header Type register of function 0 is 1), then all
> remaining Function Numbers will be checked.
>
> So what my proposal would do is set the bit for all functions.
> I don't think it matters - do you?
> If you want to try and match the behaviour you observe
> in actual hardware exactly, we can add
> /* Some devices only set multifunction status bit in function 0. */
> static void pci_clear_multifunction(...) {
> if (PCI_FUNC(dev->devfn))
> dev->config[PCI_HEADER_TYPE] &= ~PCI_HEADER_TYPE_MULTI_FUNCTION;
> }
>
> and devices can call this in their init routine.
Personally I'm okay with either way as long as you accept the patch series.
In fact the existing qemu PIIX3/4 sets the bit of only function 0
and doesn't set the bit of function > 0.
- It would be better not to change the existing behavior.
- If all functions in a device are required to set multifunction bit,
pci ide and ochi usb initialization code must be touched
for pc and mips malta.
Said that, which way do you want to go?
- The current patches.(v5 9/9)
My preference.
- require all functions in a device to set multi function bit.
patch pci ide, ochi usb
It will result in qemu behavior change.
- require all functions in a device to set multi function bit.
patch pci ide, ochi usb.
But try not to chage the existing qemu behavior by using
pci_clear_multifunction()
--
yamahata
next prev parent reply other threads:[~2010-06-23 10:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 6:03 [Qemu-devel] [PATCH v4 0/6] pci: multi-function bit fixes Isaku Yamahata
2010-06-21 6:03 ` [Qemu-devel] [PATCH v4 1/6] pci: use PCI_DEVFN() where appropriate Isaku Yamahata
2010-06-21 11:57 ` [Qemu-devel] " Michael S. Tsirkin
2010-06-21 6:03 ` [Qemu-devel] [PATCH v4 2/6] pci: remove PCIDeviceInfo::header_type Isaku Yamahata
2010-06-21 6:03 ` [Qemu-devel] [PATCH v4 3/6] pci: set PCI multi-function bit appropriately Isaku Yamahata
2010-06-21 9:45 ` [Qemu-devel] " Juan Quintela
2010-06-21 9:52 ` Isaku Yamahata
2010-06-21 12:36 ` Michael S. Tsirkin
2010-06-23 7:25 ` Isaku Yamahata
2010-06-23 9:52 ` Michael S. Tsirkin
2010-06-23 10:13 ` Isaku Yamahata [this message]
2010-06-23 10:41 ` Michael S. Tsirkin
2010-06-23 23:48 ` Isaku Yamahata
2010-06-24 8:19 ` Michael S. Tsirkin
2010-06-21 6:03 ` [Qemu-devel] [PATCH v4 4/6] pci: don't overwrite multi functio bit in pci header type Isaku Yamahata
2010-06-21 13:15 ` [Qemu-devel] " Michael S. Tsirkin
2010-06-21 6:04 ` [Qemu-devel] [PATCH v4 5/6] pci: use pci_create_simple_mf() Isaku Yamahata
2010-06-21 6:04 ` [Qemu-devel] [PATCH v4 6/6] pci_bridge: make pci bridge aware of pci multi function bit Isaku Yamahata
2010-06-21 13:22 ` [Qemu-devel] " Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100623101338.GD3471@valinux.co.jp \
--to=yamahata@valinux.co.jp \
--cc=aurelien@aurel32.net \
--cc=blauwirbel@gmail.com \
--cc=mst@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
--cc=yu.liu@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.