All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Gordeev <agordeev@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: kvm@vger.kernel.org, drjones@redhat.com, jan.kiszka@web.de,
	rkrcmar@redhat.com, pbonzini@redhat.com
Subject: Re: [PATCH kvm-unit-tests v5 09/14] pci: provide pci_scan_bars()
Date: Mon, 21 Nov 2016 20:24:13 +0100	[thread overview]
Message-ID: <20161121192413.GD30468@agordeev.lab.eng.brq.redhat.com> (raw)
In-Reply-To: <20161121072713.GG3692@pxdev.xzpeter.org>

On Mon, Nov 21, 2016 at 03:27:13PM +0800, Peter Xu wrote:
> On Wed, Nov 16, 2016 at 10:50:37AM +0100, Alexander Gordeev wrote:
> 
> [...]
> 
> > >  struct pci_dev {
> > >  	uint16_t bdf;
> > > +	phys_addr_t bar[PCI_BAR_NUM];
> > 
> > This questions pop up time and again. If bars are 32 or 64 bit?
> > What if bar is not 64 aligned? etc.
> 
> Could you help elaborate what does "not 64 aligned" mean here? AFAIU
> the bar can only be either 32bit or 64bit wide?

Let's use your example below.

> > I guess, it worth mentionig in comment that bar[] array here does
> > not match PCI header binary layout.
> 
> Not sure whether you mean this:
> 
>     void pci_scan_bars(struct pci_dev *dev)
>     {
>         int i, cur = 0;
> 
>         for (i = 0; i < PCI_BAR_NUM; i++) {
>             if (!pci_bar_is_valid(dev, i))
>                 continue;
>             dev->bar[cur++] = pci_bar_get_addr(dev, i);
>             if (pci_bar_is64(dev, i))
>                 i++;
>         }
>     }
> 
> Assume that we have a device with:
> 
> - bar 0: 32 bit addr A0
> - bar 1: 64 bit addr A1
> - bar 2: 32 bit addr A2
> 
> The original patch will generate:
> 
>   dev->bar[0] == A0
>   dev->bar[1] == A1
>   dev->bar[2] == 0
>   dev->bar[3] == A2
>   dev->bar[4] == 0
>   dev->bar[5] == 0
> 
> The new code (above) will generate:
> 
>   dev->bar[0] == A0
>   dev->bar[1] == A1
>   dev->bar[2] == A2
>   dev->bar[3] == 0
>   dev->bar[4] == 0
>   dev->bar[5] == 0

So in all three cases (PCI header, 6 32-bit words and
6 64-bit physical addresses) the term 'bar' is somehow
correct.

Yet it is confusing, because in the first two cases it reflects
device PCI header layout (6 32-bit words) while in the latter
case it is a physical address.

My suggestion is to rename pci_dev::bar[] to pci_dev::resource[]
to uncouple what is stored in this array (addresses) from PCI
header layout.

> Thanks,
> 
> -- peterx

  reply	other threads:[~2016-11-21 19:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 22:24 [PATCH kvm-unit-tests v5 00/14] VT-d unit test Peter Xu
2016-11-15 22:24 ` [PATCH kvm-unit-tests v5 01/14] pci: fix missing extern for pci_testdev() Peter Xu
2016-11-16  9:26   ` Andrew Jones
2016-11-15 22:24 ` [PATCH kvm-unit-tests v5 02/14] x86/asm: add cpu_relax() Peter Xu
2016-11-15 22:24 ` [PATCH kvm-unit-tests v5 03/14] libcflat: introduce is_power_of_2() Peter Xu
2016-11-15 22:24 ` [PATCH kvm-unit-tests v5 04/14] x86: intel-iommu: add vt-d init test Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 05/14] libcflat: add IS_ALIGNED() macro, and page sizes Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 06/14] libcflat: moving MIN/MAX here Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 07/14] vm/page: provide PGDIR_OFFSET() macro Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 08/14] pci: introduce struct pci_dev Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 09/14] pci: provide pci_scan_bars() Peter Xu
2016-11-16  9:50   ` Alexander Gordeev
2016-11-21  7:27     ` Peter Xu
2016-11-21 19:24       ` Alexander Gordeev [this message]
2016-11-22  2:16         ` Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 10/14] pci: provide pci_enable_defaults() Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 11/14] pci: edu: introduce pci-edu helpers Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 12/14] x86: intel-iommu: add dmar test Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 13/14] pci: add msi support for 32/64bit address Peter Xu
2016-11-21 19:27   ` Alexander Gordeev
2016-11-22  4:59     ` Peter Xu
2016-11-22  7:03       ` Alexander Gordeev
2016-11-22  7:21         ` Peter Xu
2016-11-22 12:30           ` Andrew Jones
2016-11-23  2:40             ` Peter Xu
2016-11-23 10:36               ` Andrew Jones
2016-11-23 10:39                 ` Peter Xu
2016-11-15 22:25 ` [PATCH kvm-unit-tests v5 14/14] x86: intel-iommu: add IR MSI test Peter Xu

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=20161121192413.GD30468@agordeev.lab.eng.brq.redhat.com \
    --to=agordeev@redhat.com \
    --cc=drjones@redhat.com \
    --cc=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=rkrcmar@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.