From: "Michael S. Tsirkin" <mst@redhat.com>
To: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] pci/pcie: make pci_find_device() ARI aware.
Date: Fri, 21 Jan 2011 16:29:41 +0200 [thread overview]
Message-ID: <20110121142940.GB6980@redhat.com> (raw)
In-Reply-To: <20110121104416.GE20801@valinux.co.jp>
On Fri, Jan 21, 2011 at 07:44:16PM +0900, Isaku Yamahata wrote:
> On Thu, Jan 20, 2011 at 04:15:48PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Jan 20, 2011 at 03:57:39PM +0900, Isaku Yamahata wrote:
> > > make pci_find_device() ARI aware.
> > >
> > > Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
> > > ---
> > > hw/pci.c | 7 +++++++
> > > 1 files changed, 7 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/hw/pci.c b/hw/pci.c
> > > index 8d0e3df..851f350 100644
> > > --- a/hw/pci.c
> > > +++ b/hw/pci.c
> > > @@ -1596,11 +1596,18 @@ PCIBus *pci_find_bus(PCIBus *bus, int bus_num)
> > >
> > > PCIDevice *pci_find_device(PCIBus *bus, int bus_num, int slot, int function)
> > > {
> > > + PCIDevice *d;
> > > bus = pci_find_bus(bus, bus_num);
> > >
> > > if (!bus)
> > > return NULL;
> > >
> > > + d = bus->parent_dev;
> > > + if (d && pci_is_express(d) &&
> > > + pcie_cap_get_type(d) == PCI_EXP_TYPE_DOWNSTREAM &&
> > > + !pcie_cap_is_ari_enabled(d) && slot > 0) {
> > > + return NULL;
> > > + }
> > > return bus->devices[PCI_DEVFN(slot, function)];
> > > }
> >
> > I'd like to split this express-specific code out in some way.
> > Further, the downstream port always has a single slot.
> > Maybe it shouldn't be a bus at all, but this needs some thought.
>
> Yes, it needs consideration.
>
>
> > How about we put flag in PCIBus that says that a single
> > slot is supported? Downstream ports would just set it.
>
> So such a flag must be set/clear by something like pcie_cap_ari_write_config()
> depending on ARI bit at runtime.
Well, to figure it out, could you please describe what is the situation
your patch tries to fix? I would generally would like a reason for the
change to be given in commit logs, please try to avoid just restating
what the patch does.
Are you trying to create a device with > 8 functions?
If that is the case I suspect this is not the best way
to do this at all.
> pcie device can have 256 functions instead of 8.
Only if it's an ARI device. And note that if you have a device with
256 functions and disable ARI in the port, it appears as
multiple devices.
> Maybe we'd like to emulate how p2p bridge transfers pci transaction
> to child pci bus somehow.
To support > 8 functions per device, some refactoring would be needed:
you can not figure out slot and function from the root bus,
it depends on ARI along the way. So APIs that pass in
decoded slot/function do not make sense anymore,
you must pass in devfn all the way.
But since everyone decodes and encodes them in the same way,
many things will work even without decoding.
--
MST
next prev parent reply other threads:[~2011-01-21 14:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-20 6:57 [Qemu-devel] [PATCH] pci/pcie: make pci_find_device() ARI aware Isaku Yamahata
2011-01-20 14:15 ` [Qemu-devel] " Michael S. Tsirkin
2011-01-21 10:44 ` Isaku Yamahata
2011-01-21 14:29 ` Michael S. Tsirkin [this message]
2011-01-21 16:39 ` Isaku Yamahata
2011-01-23 15:57 ` Michael S. Tsirkin
2011-01-24 11:39 ` Isaku Yamahata
2011-01-24 12:09 ` 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=20110121142940.GB6980@redhat.com \
--to=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yamahata@valinux.co.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).