kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Alexander Gordeev <agordeev@redhat.com>
Cc: kvm@vger.kernel.org, Thomas Huth <thuth@redhat.com>,
	Andrew Jones <drjones@redhat.com>
Subject: Re: [kvm-unit-tests PATCH v7 06/13] pci: Rework pci_bar_addr()
Date: Fri, 14 Oct 2016 14:23:55 +0800	[thread overview]
Message-ID: <20161014062355.GA31091@pxdev.xzpeter.org> (raw)
In-Reply-To: <20161013141603.GE30384@agordeev.lab.eng.brq.redhat.com>

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.

If you see PCI Local Bus Spec Rev 3.0, chap 6.2.5.1:

    Power-up software needs to build a consistent address map before
    booting the machine to an operating system. This means it has to
    determine how much memory is in the system, and how much address
    space the I/O controllers in the system require. After determining
    this information, power-up software can map the I/O controllers
    into reasonable locations and proceed with system boot. In order
    to do this mapping in a device independent manner, the base
    registers for this mapping are placed in the predefined header
    portion of Configuration Space.

BARs for each PCI devices should be pre-allocated during power-up
software, and a consistent map is built with the knowledge of existing
RAM in the system.

If you boot a VM with/without IOMMU, you'll see that BAR addresses
won't change before/after enabling IOMMU.

Thanks,

-- peterx

  reply	other threads:[~2016-10-14  6:23 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 [this message]
2016-10-14  6:55             ` Andrew Jones
2016-10-14  9:09               ` Peter Xu
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=20161014062355.GA31091@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 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).