From: Peter Xu <peterx@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Alexander Gordeev <agordeev@redhat.com>,
kvm@vger.kernel.org, Thomas Huth <thuth@redhat.com>
Subject: Re: [kvm-unit-tests PATCH v7 06/13] pci: Rework pci_bar_addr()
Date: Fri, 14 Oct 2016 17:09:21 +0800 [thread overview]
Message-ID: <20161014090921.GB31091@pxdev.xzpeter.org> (raw)
In-Reply-To: <20161014065520.6dh2hqyjlloqcnss@hawk.localdomain>
On Fri, Oct 14, 2016 at 08:55:20AM +0200, Andrew Jones wrote:
> Hi Peter,
>
> On Fri, Oct 14, 2016 at 02:23:55PM +0800, Peter Xu wrote:
> > On Thu, Oct 13, 2016 at 04:16:03PM +0200, Alexander Gordeev wrote:
> > > On Thu, Oct 13, 2016 at 02:40:35PM +0800, Peter Xu wrote:
> > > > > > > + return pci_translate_addr(dev, addr);
> > > > > >
> > > > > > Raw question: do we need to translate bar addresses as well?
> > > > >
> > > > > I believe, yes.
> > > > >
> > > > > Unless we always have identity mapping between PCI address space and
> > > > > CPU physical address space I can not realize how could it be done
> > > > > otherwise. But even if we were, I would leave the translation routine
> > > > > for clarity.
> > > >
> > > > Sorry I didn't quite catch your point. Are we talking about IOMMU
> > > > address remapping here? IMHO BAR addresses are from CPU's point of
> > > > view. It's only used by CPU, not device. In that case, BAR address
> > > > should not be translated at least by IOMMU (no matter for x86/arm or
> > > > whatever).
> > > >
> > > > Take Linux as example: pci_ioremap_bar() is responsible to be called
> > > > for any PCI drivers to map device memory bars into kernel virtual
> > > > address space. Basically it does:
> > > >
> > > > void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar)
> > > > {
> > > > struct resource *res = &pdev->resource[bar];
> > > > return ioremap_nocache(res->start, resource_size(res));
> > > > }
> > > >
> > > > So as it is written: I believe we don't translate the bar address
> > > > (which should be res->start). We use it as physical address.
> > > >
> > > > Or, do you mean other kinds of translation that I don't aware of?
> > >
> > > Yes, I mean translation from PCI bus address space to CPU physical
> > > address space. These two busses are different and hence need a
> > > translation. I assume Linux pci_dev::resource[] have translated
> > > address, but it is not what PCI devices see. Unless I do not terribly
> > > missing somethig, BAR addresses is what a device sees on its AD[0..31]
> > > pins.
> >
> > I believe pci_dev::resource[] should be assigned by BIOS or something
> > before Linux. At that time, IOMMU is possibly even not inited. So no
> > chance for a translation at all.
>
> kvm-unit-tests != Linux
>
> kvm-unit-tests/arm doesn't have a bootloader at all (not counting QEMU
> initializing registers, and a handful of QEMU generated instructions
> that gives us a kick)
>
> Anyway, I'm glad you're reviewing this series (my PCI skills are
> minimal), but you'll have to review it in the right context. In
> this case, more of a seabios context.
Thank you for pointing out. :-)
I know little about PCI as well, just want to know the fact on how we
should treat BAR addresses. So I'd say my comments are more like
questions rather than I disagree with the changes. E.g., even if we
don't have BIOS, do we really need to translate BAR addresses on ARM?
Sorry if I brought too much noise to this thread. Looking forward to
Alex's further works.
Thanks!
-- peterx
next prev parent reply other threads:[~2016-10-14 9:09 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 12:07 [kvm-unit-tests PATCH v7 00/13] PCI bus support Alexander Gordeev
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 01/13] pci: Fix coding style in generic PCI files Alexander Gordeev
2016-08-18 11:37 ` Thomas Huth
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 02/13] pci: x86: Rename pci_config_read() to pci_config_readl() Alexander Gordeev
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 03/13] pci: Add 'extern' to public function declarations Alexander Gordeev
2016-08-17 13:49 ` Andrew Jones
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 04/13] pci: x86: Add remaining PCI configuration space accessors Alexander Gordeev
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 05/13] pci: Factor out pci_bar_get() Alexander Gordeev
2016-08-18 11:39 ` Thomas Huth
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 06/13] pci: Rework pci_bar_addr() Alexander Gordeev
2016-09-23 7:14 ` Peter Xu
2016-09-23 8:51 ` Andrew Jones
2016-09-23 8:58 ` Peter Xu
2016-10-12 14:37 ` Alexander Gordeev
2016-10-13 6:40 ` Peter Xu
2016-10-13 14:16 ` Alexander Gordeev
2016-10-14 6:23 ` Peter Xu
2016-10-14 6:55 ` Andrew Jones
2016-10-14 9:09 ` Peter Xu [this message]
2016-10-14 12:37 ` Alexander Gordeev
2016-10-19 3:46 ` Peter Xu
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 07/13] pci: Add pci_bar_set_addr() Alexander Gordeev
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 08/13] pci: Add pci_dev_exists() Alexander Gordeev
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 09/13] pci: Add pci_print() Alexander Gordeev
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 10/13] pci: Add generic ECAM host support Alexander Gordeev
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 11/13] arm/arm64: pci: Add PCI bus operation test Alexander Gordeev
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 12/13] pci: Add pci-testdev PCI bus test device Alexander Gordeev
2016-08-17 14:03 ` Andrew Jones
2016-09-23 7:25 ` Peter Xu
2016-09-23 8:55 ` Andrew Jones
2016-10-12 16:54 ` Alexander Gordeev
2016-10-13 6:52 ` Peter Xu
2016-10-13 13:16 ` Alexander Gordeev
2016-10-14 5:01 ` Peter Xu
2016-10-14 7:07 ` Andrew Jones
2016-10-14 9:14 ` Peter Xu
2016-08-17 12:07 ` [kvm-unit-tests PATCH v7 13/13] arm/arm64: pci: Add pci-testdev PCI device operation test Alexander Gordeev
2016-08-17 14:26 ` [kvm-unit-tests PATCH v7 00/13] PCI bus support Andrew Jones
2016-08-23 18:28 ` Alexander Gordeev
2016-09-22 11:10 ` Andrew Jones
2016-09-28 6:33 ` Peter Xu
2016-10-12 8:00 ` Alexander Gordeev
2016-10-12 10:59 ` Peter Xu
2016-10-12 14:35 ` Alexander Gordeev
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=20161014090921.GB31091@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=agordeev@redhat.com \
--cc=drjones@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=thuth@redhat.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.